Based in the Statement List - STL, of the STEP 7, the list of instructions implemented in the SimuPLC 4.1.0 got its inspiration from STL model in all basic instructions, however differs of this equipment concerning at specialized instructions, as well as to the subroutines calls, PID loops, communication of bytes by the simulated Ports and handling of interruptions.
The IL adds too one instruction of the form //=VAR VarProgram NameMeaningful, that associates a program variable to a meaningful name (it begins with //, the indicator of comments in the STL, for this instruction does not generate error of compilation in case of adaptation of the program into IL for the STEP 7 or similar equipment - notice that in the STL the association of variables to meaningful names can be made into tables aside, one for the global variables, in the principal program, and other for the local variables in subroutines and in modules of interrupt handling). The IL introduces, likewise, an instruction of temporization that there isn't in the STL - the TOFR, maped by the instruction into LCE of the form exemplified below:
when_not (cond) temporize_accumulate VarTemporization Time;
The principal difference in relationship to the STL, though, is that, in the SimuPLC 4.1.0, the instructions bring, at most, 3 (three) parameters, and don't implement the concept of tables, what makes the process of compilation more runaway, without large loss of the expressive strength of the language in its basic implemented instructions.
Thus, without the use of tables, the instruction PID call, that needs of 8 parameters, must be made on the List of Instructions of the SimuPLC by 4 instructions, SPID1, SPID2, SPID3 e PID.
The subroutines calls, in the SimuPLC 4.1.0, are made with a maximum of 2 (two) parameters, passed by value, that is, whichever changes made in these parameters restricts to the parameter and not affect the variable utilized in the instruction caller. However, the parameters constitute always global variables to the program as whole, not thering be yet implementation of the concept of local variables in the SimuPLC 4.1.0.
The SimuPLC admits, concerning to basic instructions of manipulation bit-logic storage (=), and (A), or (O), ALD e OLD, besides of the STL format STEP 7, also the forms of IEC 1131-3 norm: storage (ST), and (AND), or (OR), ANDLD and ORLD. The instruction load (LD) presents the same form in the STL as in the IEC 1131-3 and the instructions set (S) and reset (R) present almost the same form in both (the difference is that in the STL there is a second parameter denoting the number of bit variables from first will be set or reset - into IEC 1131-3 norm there isn't this parameter and in the IL of SimuPLC 4.1.0 such parameter can be absent or present, but only for compilation compatibility with the STL, because always, independent of the value placed there, it will be considered only as equal to 1 by the Simulator).
The structure of simplified context free grammar of the language IL implemented into SimuPLC 4.1.0, in the Backus-Naur Form (BNF), is the following:
Simplified Grammar of the Instruction List - IL
il -> variable il
variable -> variav param, paramVar variable | e
il -> network param circuit more_il
more_il -> network param circuit more_il | e
circuit -> begin middle end_circuit more_circuit
more_circuit -> begin middle end_circuit more_circuit | e
begin -> load paramVar |
load_compar param1, param2 |
next |
label param |
subroutine param param_call param_call |
interr param param_call param_call |
seq_load paramVar |
seq_end
middle -> and_or paramVar middle |
and_or_compar param1, param2 middle |
lps middle end_circuit circuit_lps |
load paramVar middle |
load_compar param, param middle |
ald_old middle | e
circuit_lps -> lpp middle |
lrd middle end_circuit circuit_lps
end_circuit -> coil paramVar param_call continue |
compon1T1V paramVar continue |
compon1T2V param, paramVar continue |
compon2T1V paramVar continue |
compon2T2V paramVar, param continue |
compon3T2V paramVar, param continue |
for paramVar, param1, param2 continue |
jump param continue |
call param param_call param_call continue |
cret continue |
creti continue |
eni continue |
disi continue |
atch param, param continue |
dtch param continue |
rcv param, param continue |
xmt param, param continue |
seq_transf paramVar continue |
spid1 param1, param2
spid2 param1, param2, param3
spid3 param1, param2, param3
Pid param1, param2, param3
param_call -> , param | e
continue -> middle end_circuit | e
where paramVar (parameter variable variant) is a name that starts with a letter, and can have until 255 any characters, param (parameter) can be, besides a name like the former, also a constant, formed by digits, where the decimal point is the dot, and compon1T1V, compon1T2V, compon2T1V, compon2T2V, and compon3T2V are components with 1, 2 or 3 terminals of input and that act on 1 or 2 variable, respectively.
Obs.1: the variables and instructions in the SimuPLC are case sensitive, that is, it's considered different the lower and upper case of the same letter. Generally, the instructions into IL are written in upper, and, into LCE, in lower case.
Obs.2: the commas separating the parameters are optional, because the effective separator is the space, what implies that the parameters cannot contain spaces.
Obs.3: this grammar is simplified, since it generates some source programs that, even so, compile with errors in the implemented compiler, by cause of other consistencies/restrictions made by the IL compiler implemented within Simulator. Such consistencies would be of difficult or impossible representation in a free-context grammar. However it continues useful by generate a superset of the valid programs into IL, that is, the adequacy to it isn't sufficient but it's necessary, because if the program can't be generated by the grammar, it isn't valid, although such generation does not guarantee assurance of validity.