IL Compiler

J

Thread Starter

Jiri Baum

Hello,

I've dusted off my old Perl-based IL compiler, which turns simple instruction list into C. (The Makefile then compiles it to executable.)

Unless there are any objections, I'll check it into the CVS at lang/il (or should that be logic/il ?)

The intention is to replace it at some stage with a C program.


Quick summary of the instructions (example at end):
==================================================

First, sorry about not using the standard instructions - whoever has 1131-3
handy, can you tell me what they're supposed to be, please?

LD contact = start rung
AND contact = series contact
OR contact = parallel contact
OUT coil = normal relay coil

LDI, ANI, ORI, OUTI - above with inverted (N/C) sense

SET coil = latch coil
RST coil = unlatch coil

There are no brackets at present. Instead, the ANB and ORB instructions
must be used: for example, ANB ands in the previous rung (and forgets it so
the next ANB/ORB gets the one before). It is intended that the C program
will handle both this and brackets.

MCS = use the current rung (so far) as a rung prefix from now on.
MCE = cancel MCS.

JMP label = conditionally jump to the label
LBL label = label marker (no operation)

END = end of program (unconditional - only a JMP gets past it)
NOP = no operation

Comments begin with # or ; and must be alone on a line.


Example:
=======

The following stepladder diagram:

| X001 Y002 Y004 |
|---[ ]---[ ]---+-----------------( )----|
| | |
| X002 Y001 | |
|---[ ]---[/]---+ |
| |

Is written:

LD X001
AND Y002
LD X002
ANI Y001
ORB
OUT Y004

And comes out as per the attached example.c


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Jiri Baum wrote:

> I've dusted off my old Perl-based IL compiler, which turns simple
> instruction list into C. (The Makefile then compiles it to executable.)
>
> Unless there are any objections, I'll check it into the CVS at lang/il (or
> should that be logic/il ?)

sounds logic/al to me :^)

Hi Jiri.

Can this be hacked easily to produce a function rather than a standalone? Which brings up another question, can a solver be standalone? or should we
maintain the read, solve, write sequence? We could, I suppose synchronise the solver to the IO using another semaphore, but we would soon run into the scheduling thing if the IO slept and the solver became ready to run.

> The intention is to replace it at some stage with a C program.

Perl is ok here as it's only run to cook a new program. C would make it a lot easier to wedge into an embedded class machine though, the perl
stuff is rather large for flash.

> Quick summary of the instructions (example at end):
> ==================================================
>
> First, sorry about not using the standard instructions - whoever has 1131-3
> handy, can you tell me what they're supposed to be, please?
>
> LD contact = start rung
> AND contact = series contact
> OR contact = parallel contact
> OUT coil = normal relay coil
>
> LDI, ANI, ORI, OUTI - above with inverted (N/C) sense
>
> SET coil = latch coil
> RST coil = unlatch coil
>
> There are no brackets at present. Instead, the ANB and ORB instructions
> must be used: for example, ANB ands in the previous rung (and forgets it so
> the next ANB/ORB gets the one before). It is intended that the C program
> will handle both this and brackets.
>
> MCS = use the current rung (so far) as a rung prefix from now on.
> MCE = cancel MCS.
>
> JMP label = conditionally jump to the label
> LBL label = label marker (no operation)
>
> END = end of program (unconditional - only a JMP gets past it)
> NOP = no operation
>
> Comments begin with # or ; and must be alone on a line.
>
> Example:
...<clip>...
> And comes out as per the attached example.c

Good going, Jiri

I've been contemplating what would go into a small library of special functions like one-shots, fifo's, flipflops, timers, math, etc. That way we could test and use the same functions referred to symbolically, rather than coding them in C on the fly. Maybe like:
MULT R1 R2 R3
Meaning multiply R1 * R2 with the result in R3. Variables and constants would be good to have also. I'm not familiar with IL of any sort so can we get info on how these are handled?

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > I've dusted off my old Perl-based IL compiler, which turns simple
> > instruction list into C. (The Makefile then compiles it to executable.)

> > Unless there are any objections, I'll check it into the CVS at lang/il
> > (or should that be logic/il ?)

Curt Wuollet:
> sounds logic/al to me :^)

OK :)

Do you think logic/il or lang/il is better? Probably logic/il, on second thoughts...

> Can this be hacked easily to produce a function rather than a standalone?

Yes - if you look at the output, you'll see that the bulk of it is in a function, with just a little "main" at the bottom.

> Which brings up another question, can a solver be standalone? or should
> we maintain the read, solve, write sequence?

Normally, it should be standalone - that was the point of the entire Shared Memory thing. Take a look at the basic demo - there's about four processes there, each doing its bit...

Don't forget, as discussed in January[1] and May[2], the *semantics* of the read-solve-write sequence are maintained; we're just trading scanning time against latency. (From the solver's point of view, io-scanning time is near-zero, and the latency is correspondingly larger.)

> We could, I suppose synchronise the solver to the IO using another
> semaphore, but we would soon run into the scheduling thing if the IO
> slept and the solver became ready to run.

For now, I'd leave it free-running and see what happens.

Later, we'll put in mechanisms for synchronising things together. But even then you don't necessarily want to synchronise everything together - slow I/O should be left alone to run slowly, as should any ponderous modules of the logic/calculation.

There's no problem with the scheduling thing if we are using semaphores: when the solver is sleeping on the synch semaphore, it's not ready to run.

> > The intention is to replace it at some stage with a C program.

> Perl is ok here as it's only run to cook a new program. C would make it a
> lot easier to wedge into an embedded class machine though, the perl stuff
> is rather large for flash.

Well, the perl just cooks the program, you can flash the resulting C (maybe
put the .il file there as well, in case you want to gdb the thing).

The real reason for replacing it is that, as it stands, it needs a good
re-design. Now I can re-design it in perl or python or lex/yacc/C, but I
thought we basically agreed to do everything in C...

> Good going, Jiri

Thanks :)

> I've been contemplating what would go into a small library of special
> functions like one-shots, fifo's, flipflops, timers, math, etc.

And rising/falling edge detectors. Some I/O modules will want that, even.

But first I'd like a curses-based screen thing, and for that I need the config parser, which I started a week ago and then got some flu or other.

> That way we could test and use the same functions referred to
> symbolically, rather than coding them in C on the fly. Maybe like:
> MULT R1 R2 R3
> Meaning multiply R1 * R2 with the result in R3.

Yup - for that we need multi-bit points, another thing that's in the pipeline...

> Variables and constants would be good to have also.

Variables can be done as registers in the shared memory (then the other modules can look at them - including the HMI).

Constants would be read from linuxplc.conf at startup time.

> I'm not familiar with IL of any sort so can we get info on how these are
> handled?

Not sure.


Jiri

footnotes:
[1] see eg my e-mail "Re: LinuxPLC: Design (long) - take 3" of 16 Jan 2000.
[2] see eg my e-mail "Re: LinuxPLC: Step3" of 5 May 2000
or "Re: LinuxPLC: Design tickler" of 12 May 2000.
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Jiri Baum wrote:

<clip>.....
> There's no problem with the scheduling thing if we are using semaphores:
> when the solver is sleeping on the synch semaphore, it's not ready to run.

I've gotta think this through. Right now, it looks like a good job for a RT scheduler with IO, solver, display&general in decreasing priority. I'm waiting for stuff from montavista (Hard Hat Linux) This should be sorted out while we're still small and simple enough to change easily.

> > > The intention is to replace it at some stage with a C program.
>
> > Perl is ok here as it's only run to cook a new program. C would make it a
> > lot easier to wedge into an embedded class machine though, the perl stuff
> > is rather large for flash.
>
> Well, the perl just cooks the program, you can flash the resulting C (maybe
> put the .il file there as well, in case you want to gdb the thing).
>
> The real reason for replacing it is that, as it stands, it needs a good
> re-design. Now I can re-design it in perl or python or lex/yacc/C, but I
> thought we basically agreed to do everything in C...

Yes, it's better that way so even a small machine can be self hosting. Flex/Bison/C would be powerful, I have to check how they are on
resources. It would be handy if you didn't need a desktop or laptop to program the PLC.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > > > The intention is to replace it at some stage with a C program.
..
> > The real reason for replacing it is that, as it stands, it needs a good
> > re-design. Now I can re-design it in perl or python or lex/yacc/C, but
> > I thought we basically agreed to do everything in C...

Curt Wuollet:
> Yes, it's better that way so even a small machine can be self hosting.
> Flex/Bison/C would be powerful, I have to check how they are on
> resources. It would be handy if you didn't need a desktop or laptop to
> program the PLC.

Unlike a perl program, flex and bison produce C code rather than interpreting the source file directly. So when you are programming the PLC (as opposed to modifying it), you don't need to run them, just the resulting parser.

The lexer and parser are state machines, so they shouldn't be too bad.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top