Ladder parser or compiler

P

Phil Covington

Curt:

While I am sure my last post will not earn me any points for tactfulness, your dismissal of Hugh Jack's excellent code based on programming language really yanked my chain I am sorry to say.

Curt Wuollet wrote:

>Hi all
>
>So much for the olive branch........ Still hate to see you go, Phil. As I said
>when you went over to the NT side, I'm not out to exclude anyone.

Went over to the NT side??? Don't you mean "went over to the dark side"? :)

I have the opportunity to do some development work on a soft plc, and it happens that it must run on NT. I do plan on releasing the source under a BSD License or GPL though. Most of the code *will* be portable and if it turns out well I will port it to Linux as time permits. That I am developing it for a MS product is what gives you heartburn I suspect...

There are __many__ people using NT that we cannot ignore. Consider this: If a open source soft plc project on NT attracts people because of its
openness and there is also an equivalent effort in Linux, then there is an opportunity to
'convert' people to your beloved Linux OS.

Let me state now that I am definitely not a fan of Bill Gates or Microsoft. I began using Linux in 1997 because of my dissatisfaction with Windows. I have very positive experiences with W2K though, and I have begun to rethink my position on MS and Windows. With W2K and Linux I have the best of both worlds and it doesn't require me to exclude either OS. I am very impressed with the Linux kernel (have you ever actually sat down and gone through it?), but
IMHO, I think that the X Window system and many of the apps still leave a lot to be desired. Of
course, X Window and the apps are not really _Linux_ are they?

I am turned off by both Windows and Linux zealots and their all-or-nothing views. I use software as a tool to get a job done and as long as it works, I am happy.

>It's
>got to be a community effort. I agree that it's a good approach and well
>crafted. And it's more than anyone has contributed to date And as I also
>said, it's for the listers to decide and I will yield to democracy. I'm
not
>going to debate good and evil with you Phil.

Where did I mention good or evil in my last post? You are the one that seems to want
to make your OS choice and the open source movement an issue of morality and ethics...

Just re-read your response to my message a while back when I said that I was going to concentrate on NT right now. I believe you used the words "moral" and "ethical"...

>I do feel quite strongly that we need to include as many people as possible
>in a community project. I also believe that to keep it from being
exploited,
>we need the GPL. I also believe that Linux and the free GNU tools make
>it possible for anyone from a poor student to a company president to
>participate and deploy the result on an equal basis with equal ownership.
>I'm not sure how you construe that as elitist, that remark actually hurt.

All one has to do is read your past messages in the Automation List concerning open source vs proprietary or your feelings towards Microsoft to come to that conclusion. Somehow you feel that open source is more ethical and that proprietary
is evil. MS users are just mindless lemmings or clueless and your choice in an OS is somehow enlightened and "right"...

I applaud those who release their software projects as open source, but I do not condemn or think less of those who keep their products proprietary.

>I am a Linux bigot, that has a lot to do with the principles above and a
>deep appreciation for the countless developers who literally give their
>lifes work so that I can afford to run a world class OS with world class
>tools, I owe much of what I know and how I make my living to people
>who share knowlege and information freely. This project is an attempt
>to meet that standard and pass on the only advantage that I have been
>given. If that sounds silly and idealistic and makes this a pipedream, so
>be it. RMS and I don't see eye to eye either, but, I respect his point of
>view. This is perhaps the most adverse, commercialized environment
>to attempt a community effort in and I expected some unpleasantness.

And no more unpleasant than many of the open source/ Linux advocates that can't get over the fact that the world does not bend to their idealistic wishes.

Their endless criticism and rhetoric does as much to turn off people to the idea of open source projects as it does to open peoples minds to the open source idea.

>If there is to be no community around it and the principles don't mean
>anything, it would be simpler and faster to pass the hat and pay some
>CS mercenaries to do it. Then how they did it could be kept secret and
>sold for what the market would bear. It would run on proprietary and
>expensive hardware and use yet another proprietary fieldbus etc. and
>nothing would change.

Not everyone has a deep seated disdain for proprietary solutions as you seem to have though...

Do you seriously think that Allen Bradley, Siemens, or whomever is going to give up and wither away just because there is an open source alternative available? Many companies like the support that they get from these proprietary
vendors and they are willing to pay the price that comes with sticking to a proprietary solution. I personally don't like having to pay big bucks for a fieldbus card when ethernet would be a much less expensive solution, but what I
personally think doesn't really matter when it comes right down to it. I can give my customers options (which would include an open source solution) but they will ultimately make the decision and I will smile and accept it. That is if I do want to keep them as a customer...

>I started to code the thing all by myself, but I
>thought and still think it would be better and mean a lot more if it were
>a community project. If I have become an obstacle to that, it's I who
>should leave. Listers, it's _your_ community and _your_ project, what
>do you think?

I think that if you continue to reject the efforts of people willing to contribute
to this project (such as Hugh Jack) then I don't think you will need worry about it. You will be the only one left here...


Regards,
Phil

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

Jack Gallagher

I agree with Mark on this. We can have different modules, programmed in different languages and still make the whole thing work. The code can also be used by anyone on any platform. This effort needs a variety of opinions. Please don't leave us Phil.

If it still matters, my opinion is that C++ is a better language for this project, but that C is also valid if the code is designed using the
principles of encapsulation. I have seen many C projects that suffered because of a lack of scalability (something that is natural to C++). The benefit of C, as Curt has correctly identified, is that it is more universally known. Although, I don't think that should be a reason to preclude C++.

As far as issues with which operating system to support, I would hope that the design would keep all operating system dependant code in one localized place, so it can be replaced as needed. I understand that this is the LinuxPLC, but why limit the capabilities? This is one of the many reasons a good design makes a better product.

Please don't take any of my comments as a sign of aggression. I am only giving my personal opinion.


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

Welcome back!

What I am trying to do is get as many as 3 people working on the same machine. This is a microcosm of the automation industry. Half a dozen people working on half a dozen approaches. If we had half a dozen people working on the same approach we would have amazing results, even if it's only coded in crude old C. That Phil, is what the project is about and if you look at my "bigotry" in that light, I am guilty as charged. If you want to compete, let's see who can write the most code on the project or who can write the best code on the project. But, if what you want to do is build a different project, it's not helping this one. I have patiently waited for a concensus. We simply get more approaches. What is first and foremost is that I find people who want to forgo competition and apply their energies in the same direction for the common good. No mystery No BS, that has been my consistant agenda. Microsoft is irrelevent to
the Linux PLC project, I haven't brought it up.

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> From: M. Robert Martin

> carry this to an extreme, and we can build it under gForth...

Actually, that would probably work quite well for a prototype if anyone understands gForth enough to hook in the IO. Of more interest is the gForth
engine. It is a *very* fast threaded code interpreter implemented in gcc (note that I did not say Ansi C because it depends on some gcc-specific features for its speed). See
http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz for details of how it works.

Clearly, the first PuffinPLC engine doesn't need to be this fast but it would be very nice to have this kind of performance later. Here are some
thoughts on how to design a logic engine to make this as easy as possible:

1. Choose a simple stack oriented object code. Make it 32-bit aligned for two reasons:
a. Support direct and indirect threading on 32 bit machines later on.
b. Many modern processors charge a heft penalty for unaligned accesses.

2. Express the opcode as a vector of instructions and operands. Think machine instructions here. Think simple, fast execution.

3. Maybe add some non-executable "opcodes" for holding information needed to support uncompiling and debugging as in typical PLCs. This trick, sometimes called "bytecode annotation", is little used but may be particularly useful in this project. The cost of these annotation opcodes is paid in code size and maybe cache misses (because of code size) -- we can almost certainly afford it.

4. Define the IO interface very carefully. Fortunately this is very easy in the current model where IO task(s) do most of this automagically through shared memory.

5. Write a simple user space interpreter for the virtual machine defined above. I'm not going to get into the C vs. C++ argument here, but I'd very
strongly suggest making the main interpreter loop look like the following:

while(1) {
opcode = *ip++;
switch (opcode) {
...
}
}

This (a.k.a. token threaded code) will be reasonably fast and easy to do. Upgrading to gforth style indirect threaded code (direct threaded loses on iX86) will probably gain a factor 2-4+ but be more work and less portable.

6. Write one or more compilers to this virtual machine (VM). I could care less what the compilers are written in or how fast they are (unless they're unbearably slow).

7. Write a programming environment or few for the compiler.

8. Convert the VM to the gforth model, make it work in the RT kernel, etc. This is fun, interesting and a waste of resources until we have a lot more done.

Issues with this approach:

1. Decompilation and debugging. This is going to be work and I've sort of swept in under the rug by suggesting annotations without defining them. The only alternative I immediately see is a VM more specifically tailored to ladder logic. This seems harder and more complex to me, possibly because I've never written one. I'd be thrilled if someone has the experience and desire to take this approach.

2. Ladder specific optimizations such as determining that none of the controlling inputs of a rung have changed (are on?) and that the entire rung can therefore be skipped. My problems with this are much the same as the
previous issue. Again, I suspect that annotations can help and can be added later (yeah, I said they weren't executed -- I lied :).

3. I've completely ignored the VM's memory model and what to do with it. This isn't so much an issue and a TBD.

I hope that this helps point one possible direction. In summary, I think that Hugh's code could be a big step forward, but that the execution engine portion should be broken off, simplified and sped up.

Dan Pierson, <[email protected]>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Phil (to Curt, in a longer conversation):
> Somehow you feel that open source is more ethical and that proprietary is
> evil.

Otherwise known as the RMS position.

(RMS = Richard M. Stallman)

I don't have a URL handy, but I expect you can find his writings from http://www.gnu.org


There are sound business reasons to use Open Source (see also ESR), and reasons related to lock-in and accountability and so forth. But, in its origins, Free Software was motivated by morality.

For some people, one of the main attractions of Free Software is this basis in ethics. For others this is not as important as the practical advantages of Open Source, but still we should not forget our origins, and we should not denigrate people for whom ethics are the determining factor.

In other words, RMS and ESR are both right.


G-d, now I've painted myself as some kind of zealot.

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
 
P

Phil Covington

Jiri,

-On RMS-

You can find his writings at: http://www.gnu.org/philosophy/philosophy.html
and yes I have read them.

I find his insistence that software is some kind of moral issue quite bazaar and that brings me to:

-ESR-

From ESR's "The Cathedral and the Bazaar":

<quote>
-----------
Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software ``hoarding'' is morally wrong
(assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.
-----------
<end quote>

I find that ESR's writings are more palatable. You can read his writings
at: http://www.tuxedo.org/~esr/writings/index.html

The "Cathedral and the Bazaar" and "Homesteading the Noosphere" are interesting reads...

-On your comments-

I don't think we should denigrate people for their decision to write proprietary software either though... Like I said in an earlier post - I applaud those who release their code as open source, but I don't think any less of those who make the choice to offer a closed source solution. To say one is evil and the other is good is complete nonsense, IMHO. I am a scientist, not an artist... but some programmers think that they are...

Regards,

Phil

----------------------------------------------------------------------------
PMS - (Premenstrual Stallman)
Function: noun
: a varying group of symptoms manifested by RMS and his lemmings when their
open source utopian world is threatened that may include emotional
instability, irritability, insomnia, fatigue, anxiety, depression, headache,
edema, abdominal pain, and hissy fits.
----------------------------------------------------------------------------

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