Why program with high level programming languages? (was PLCS: PLC Fortran)

A

Thread Starter

Anonymous

hello, i'm writing in just to enquire something.
why does someone need to program with high level programming languages? is it easier? faster? less debugging time? or some other reasons?
 
J

James Ingraham

Higher level languages generally are faster to write and easier to debug. Normally there is a performance trade-off; high-level languages like Java, Basic, and LISP go through some kind of interpreter that costs time. A mid-level language like C runs circles around these, but you have to do your own memory allocation and clean-up.

At the lowest level, assembly language is as fast as you can get, but is very difficult to program in. (Of course, a bad assembly programmer might end up with code that runs slower than a good C programmer's optimized code). Ladder logic is a very, very high-level language; you are completely isolated from the underlying architecture, there is no memory managment and rarely any file management. (Don't confuse file management with the Allen-Bradley "files"; file is really a misnomer in this case. They are really much closer to memory areas than files.)

For example, you could write a ladder logic interpretter in C, but it is impossible to write a C compiler in ladder logic. This is an acid test for determining whether a language is "high-level" or "low-level."

-James
Sage Automation, Inc.
 
G

George Robertson

Please don't take this as a flame, but we generally don't consider (computer scientists being we) ladder logic to be a high level language. It is actually on a par with assembler, with the exception of some fancy function blocks added later to the original language.

If the inability to write a compiler in the high level language is the test, here are a couple of thoughts:

ADA can be used to write cross-assemblers. Would it be a low level language?

My hand held calculator (OK, actually none of my calculators are this stupid, but let's say I got one in a box of breakfast cereal) can't be used to write a compiler. Is it a high level language?

The "acid test" makes it seem that anything of limited capability is a higher level.

In computer science, we tend to define languages by the "generation." The determining factors are platform independence, specific memory structure independence, strenght of typing, scoping of variables, flexibility of parameter passing, protection of code integrity, etc.

Otherwise, I totally agree with the below. You make a very good observation about optimizing compilers. This may not still be the case, but there was a day when you could take an optimized Waterloo FORTRAN compiler and have it smoke most assembly language programmers, whether optimized for speed or code size. Nowadays, sadly, the processors are so fast and memory so cheap that the real programmers are a dying breed.

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
[email protected]
(915) 366-4252
 
T
> Please don't take this as a flame, but we
> generally don't consider (computer scientists
> being we) ladder logic to be a high level
> language. It is actually on a par with
> assembler, with the exception of some fancy
> function blocks added later to the original
> language.

I respectfully diagree - having done quite a bit of programming in C, assembly, VB, and LL. Perhaps I am thinking from a code production point of view, but I would rank a language's level based on how much work it saves the programmer. Perhaps the most common operation in LL is the single bit test. In LL it's just one statement. In assembly you have to OR the word against a mask and check the CPU non-zero bit if the CPU supports it, or if not, you have to do an additonal comparrison. The programmer has to figure out the bit mask for each bit that is tested, quite a bit of work on his part if its a large system. It is just one instruction in LL with a simple bit designation method, that makes it a fairly high level language. The graphical program development environment for most PLCs is also rather sophisticated when compared to the traditional programming environment (text editor and compiler).

Please don't confuse the availabilty of a large library of functions (such as in C) for a language level. LL is a quite ridgid and unflexibible language when compared to the likes of C but that also in no way means it is "low level." The IEC-61131 tried to address the cross platform compatibility issue, but not too successfully.

It does provide some freedom from being tied to a specific memory structure (varies in degree by PLC brand), allowes scoped variables, and parameter passing. LL has some shortcoming, but it is still a living, evolving language (as opposed to FORTRAN, Pascal, et al), and I would rather use it for online debugging of an operating piece of machinery than any other language.
 
B

Brian E. Boothe

Yes its True that Ladder logic can appear to be a Somewhat Subset of Assembly but doesnt have the functionality of true 80xxx or 68xxx Assembly
its defined in my terms as a IN-BOX language
Tightly Bound By its Purpose..in which it only has ONE.,,, Actualy assembler or any other REAL language can take on more Personality and is only Limited by the user or (Developers) imagination
even to create another Language...or ladder Interpreter or take over what the ladder Does and forget ladder logic...Ladder Logic was created for
electricians who know nothing about software to mimic there circuits and Performing a Task Instead of Million Relays... and the comment of Real programmers being A Dying Breed???, what do u mean about Real ?? 80xxx/ 68HC11 /ASM /C++ ?DELPHI is still in full usage today ? Your
Obvioulsy Not a Real Programmer...
 
George Robertson:
> Please don't take this as a flame, but we generally don't consider
> (computer scientists being we) ladder logic to be a high level language.
> It is actually on a par with assembler, with the exception of some fancy
> function blocks added later to the original language.

Indeed, in some ways it is lower than assembler - most assemblers are symbolic, whereas most ladders expect physical memory addresses like M1.4

> You make a very good observation about optimizing compilers.
...
> Nowadays, sadly, the processors are so fast and memory so cheap that the
> real programmers are a dying breed.

Also, processors nowadays are designed more for optimizing compilers than human programmers - RISC, pipelining, etc.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
V

Vladimir Zyubin

Hello List,

LM> really much closer to memory areas than files.) For example, you could
LM> write a ladder logic interpretter in C, but it is impossible to write a C
LM> compiler in ladder logic. This is an acid test for determining whether a
LM> language is "high-level" or "low-level."

It is a wrong statement... It is impossible (in practice) to write a C compiler in the machine codes... directly... by "0"s and "1"s...
And you could write a machine codes interpreter in C. So, do you think machine-codes is a high level languages? Wrong.

"High-level" refers to the human side of the programming... "low-level" refers to the machine side... (If we take in mind that programming is a communication between human being and a dumb piece of iron :)

--
Best regards,
Vladimir mailto:[email protected]
 
G

George Robertson

If LL is High level, write some string processing, communications parsing, sequencing with multiple possible sequences, historical
logging, advanced process control, and operator interface routines in it.

Bit testing is easy in other HLLs if the functions are in the library.

(Now the gloves are coming off!)

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
[email protected]
(915) 366-4252
 
T
OK, try this. Pick your language of choice, then write a ready to execute program that takes the third bit from one 16 bit data word, tests it to be set and if it is then set the seventh bit in a different data word without changing any other bit in that word. Spend less than 15 seconds designing your program and have the program ready to execute in less than 30 seconds from the time you begin typing. Ready, set, go.

One of the reasons we have multiple languages is that each is suited to doing different things. LL excels at bit logic. I would of course never dream of parsing a string with LL. But then I don't need to parse a long string to control say a
packaging machine for example, so your comparrison fails on that point because its out of the scope of application. (LL however isn't really all that bad at short string comparrisons thay you may need to do for RS232 instrument communications)

Most PLCs use 16 or 32 bit processors, which of course means they work with 16 or 32 bit words. LL language takes care of the bit level access for you, saving you huge ammounts of work and the trouble of developing bit masks for all your desired IO cominations. The above example's solution is a PLC program that looks something
like XIC B3/2 OTE B3/22 for an AB PLC. If it was converted to assembly there would be considerably more typing to do and you would have to develop a bit mask for your test and a bit mask to write your result. In C there would be almost as many
characters typed before you even began production on useful code.
(int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!
LL was never intended for word processing and its advocates dont pretend that it ever was. But its foes so often find that as a fault. Its intent was to provide a easy to use language that saved huge ammounts of work in writing bit logic programs. Within that scope, it certianly meets the criteria to qualify as a higher level language. Sometimes the simple can be elegant and advanced.
 
J

James Ingraham

Wow! Didn't expect that response.

A few salient points from the above.

From George G. Robertson, P.E. :
>If LL is High level, write some string
>processing, communications parsing,
>sequencing >with multiple possible sequences,
>historical logging, advanced process control,
>and operator >interface routines in it.

The fact that you can't do this in Ladder Logic is precisely what makes it a "higher-level" language. Yes, your calculator is "higher-level" than your PC, precisely because it limits your functionality and in doing so makes it very, very easy to use. However, this is a moot point because your doesn't really have a programming language. (Now somebody is gonna jump on me 'cause they have some fancy calculator that runs FORTH or something.)

I do see your point. For example, Java, as a programming language, is far more powerful and flexible than Ladder Logic and is generally considered a "high-level" language. So if Ladder is so limited, how can it be high-level? Thanks, T. Connolly, for providing the answer:

>Please don't confuse the availabilty of a large
>library of functions (such as in C) for a
>language level

Remember, in C you can't even put output on the screen without a library! (C++ takes care of this). Jave needs it's libraries to get everything done, too. Ladder is the same way; there ARE PLC's that can manipulate strings, have user-defined functions, and have large libraries. Generally, these libraries are to handle PID loops or motion or some other control-oriented task. There are doubtlessly PID libraries for C, but the language itself has no inherent ability to do it.

Jiri Baum had a great point about LL often being lower-level because you talk directly to memory addresses. I haven't dealt with any of these in a while, since my company now uses nothing but ControlLogix. I really don't know how to respond to this one.

Also, to Vladimir Zyubin's point:
>It is impossible (in practice) to write a C
>compiler in the machine codes...
>directly... >by "0"s and "1"s... And you could >write a >machine codes interpreter in C. So, do
>you think >machine-codes is a high level
>languages?

It is impossible in practice to do ANYTHING in machine codes. This is not really a programming language. Since machine-codes are not a language at all (at least to us) the discussion of "high-level" or "low-level" is meaningless. But obviously, machine-codes is as low as you get.

On the issue of credibility: I am NOT a computer scientist. I am a Software Engineer, which is accurately described as "applications programmer." Many computer scientist don't write any actualy code ever. So any profs out there who want to take me to town, so be it. But I stick by my definitions, while acknowledging that this is not a cut-and-dried proposition.

-James
Sage Automation, Inc.
 
C
> From: T. Connolly
>
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word. Spend less than 15
> seconds designing your program and have the program ready to execute in
> less than 30 seconds from the time you begin typing. Ready, set, go.

No Problem. In _my_ LPLC (distinct fron the MAT/LPLC project) that becomes:
if(iX)qY else cqY;

Every language (that I know of) gives you logic operators. And coding the logic, in and of itself is simple. But it's nothing magical or even very
clever to hide all the details so all the user has to worry about is logic.

Now I've got one for you. Take a couple different cranky old NC lathes, (customer's choice) a measuring instrument (also customer's choice) a
couple different green screen terminals, one with an attached serial printer and let's throw in a barcode reader (customers choice). You get
$ 1000.00 for new hardware. The idea is to read a barcode, measure the part, factor in the measurement and upload the proper part programs to the lathes and diaplay and log the results. Show and tell is the day after tomorrow. Try not to write more than a couple pages of code.

> One of the reasons we have multiple languages is that each is suited to
> doing different things. LL excels at bit logic. I would of course never
> dream of parsing a string with LL. But then I don't need to parse a long
> string to control say a packaging machine for example, so your
> comparrison fails on that point because its out of the scope of
> application. (LL however isn't really all that bad at short string
> comparrisons thay you may need to do for RS232 instrument communications)
>
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations. The above example's
> solution is a PLC program that lookes something like XIC B3/2 OTE B3/22
> for an AB PLC. If it was converted to assembly there would be
> considerably more typing to do and you would have to develop a bit mask
> for your test and a bit mask to write your result. In C there would be
> almost as many characters typed before you even began production on
> useful code. (int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!

That's a bit unfair, you get software on the PLC. If you have the framework built, which happens only once on either, all you have to do is code the logic. This looks to be about the same length in your example and mine. Mine is even a bit more human readable IMHO but that's largely a matter
of taste. And we both have to relate the bits to I/O at some point.

> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was. But its foes so often find that as a fault. Its
> intent was to provide a easy to use language that saved huge ammounts of
> work in writing bit logic programs. Within that scope, it certianly
> meets the criteria to qualify as a higher level language. Sometimes the
> simple can be elegant and advanced.

I wouldn't argue that LL isn't a high level language since you can have some powerful functions. I would argue that a lot of real world tasks are much more than bit logic and mapping them to the relay model gets very ugly and expensive. I think the optimal solution should offer good tools for logic solving, including LL and much better tools for the rest of the
solution. As wide an array of tools as possible for the many problems encountered. Having C and Fortran and ncurses and sockets and scripting
and a serious database and every other tool you might need without reaching for the credit card, you can handle just about anything. The right tool for the job and all the tools in one box. I still wouldn't use Fortran again.

Regards

cww
 
D

Dan L. Pierson

I think that part of the problem with this discussion is a confusion between language level and generality. IMHO, the best definition of a
high level language is a language whose level of abstraction is closely matched to abstractions of the problem domain in question. This means that level and generality are best considered as two axis of a graph (please imagine it, I'll spare you my lame text graphics).

Some examples:

Assembly: Very general -- you can do anything in it with nearly equal difficulty. The difficulty of an assembly program scales non-linearly with the size of the program pretty much independent of problem domain. Very, very low level.

Basic: General for problems of limited scope. Mid level. No particular problem domain. Lacks features for handling large or complex problems. No real ability to express solutions in the domain
of the problem. See Visual Basic below.

C: Very general. Designed to do almost anything you can do with assembly. Abstractions are reasonably well suited to writing device drivers and operating systems. They are not well suited to many other domains (yes, you can design function libraries and data structures that are suited to other domains, but the resulting code is still very full of low level C details). Low to at most mid level.

C++: Very general. Very, very complex. Can do a pretty good job of raising the abstraction level close to the problem domain by proper use of generics, overloading and classes. A fair amount of basic C level cruft still tends to show through and clutter up the code. Mid/high level in general use.

Java: Looks rather like C++ at first glance but removes most of the complex and dangerous features. Can be used in many problem domains
with appropriate class libraries but basic language features always show through and clutter the code. Has features like garbage collection, array bounds checking, etc. that prevent common programmer errors. Thus, quite general, high level.

Lisp: Very general. Designed to work in the problem domain by implementing domain specific languages in lisp then solving the problem in the domain specific language. Low/mid (if you're doing things like writing lisp systems in lisp) to very high level (for serious problem solving). Not popular. Generally compiled with an optimizing compile (contrary to many impressions). One of the best languages ever created for writing compilers (the only real
competitors are the function languages such as SML).

Visual Basic: The full "language" is an IDE for writing simple GUI applications. The language is somewhat higher level than common Basic, but still lacks features for structuring and managing large programs or for expressing solutions in terms of a problem domain other than ActiveX controls. I'd still say general. Mid level for
general problem domains. Quite high level for simple GUIs.

RPG II: Designed for batch accounting problems. Very productive in that domain. Difficulty of using in any other domain quickly scales
exponentially (been there, it hurt). Thus high level, not at all general.

Ladder Logic: Designed for digital machine control. Has had features to deal with analog and motion grafted on to it, but they don't really
fit into the language model. Very productive in applications where it applies well. Not general. Level is hard to say -- the extreme
detail required and common lack of features like abstract memory addressing and basic abstraction mechanisms make it low level but the clarity and brevity of its display of domain logic make it high level.

Quickstep: Designed for machine control in discrete manufacturing. Textual language is more verbose than ladder for simple digital logic,
but does a vastly better job of integrating motion and analog. Not general outside of its domain. High level in its domain but would
benefit from adding common features of general purpose high level languages (unlike ladder, I can see how to add them to Quickstep).

The last three are examples of _domain specific languages_. I like to refer to these as nice, comfy straight jackets. They are designed both to make it easy to solve problems of specific type and to make it as hard as possible to make common mistakes in solving that type of problem. This trade off necessarily sacrifices generality. IMHO, it's a good trade off, but comparing domain specific languages and general purpose higher level languages is comparing apples and avocados.

Dan Pierson
 
T. Connolly:
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word.

As I said, LL is a 1-bit language, so dealing with 1-bit quantities is the most natural. Most other assemblies are 8-bit, so the most natural quantity to deal with is 8 bits.

FWIW, the C statement would be: "if (a&8) b|=128;" but it's the wrong way to do it (or to compare languages, for that matter).

Indeed, you shouldn't *need* to think that it's the third bit or the seventh bit; you should just assign them names once (or have them assigned
automatically, for internal coils) and then just use the names.

Then it'd become: "if (c) d=ON;" if you were going for clarity, or: "d|=c;" if you weren't.

...
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations.

Well, it pretends to be a 1-bit processor for you. Big deal. Took me all of an afternoon to write that for the MAT LPLC.

> The above example's solution is a PLC program that lookes something like
> XIC B3/2 OTE B3/22 for an AB PLC.

I'm not sure how that is the third bit or the seventh bit; in any case, it's bad that you deal with the addresses explicitly. Even in most assembly languages you can give addresses names, let alone anything higher.

> If it was converted to assembly there would be considerably more typing
> to do and you would have to develop a bit mask for your test and a bit
> mask to write your result.

Again, that's because you're trying to deal with a non-native word size.

> In C there would be almost as many characters typed before you even began
> production on useful code.

Presumably this would be just one line in a large program; in any case, amount of typing alone isn't a good indicator of language level.

> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was.

LL was intended mostly to pretend to be a relay diagram without being too much work to implement. At which it succeeded admirably, and it enabled the complication of control logic by an order of magnitude or two, but no more.

> Within that scope, it certianly meets the criteria to qualify as a higher
> level language. Sometimes the simple can be elegant and advanced.

Nope - it isn't. It's about the most primitive language you could possibly devise for writing bit logic programs. That doesn't mean it's not useful; certainly low-level languages have their place; but there's no way you can bend the definition to make it high-level.

It doesn't provide encapsulation, or code reuse, or any of those things a high level language does. The solution to Jim Pinto's problem of large
projects isn't some magical ``intelligent'' solutions but solid software engineering principles.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
James Ingraham:
> Wow! Didn't expect that response.

> A few salient points from the above.

George G. Robertson, P.E. :
> >If LL is High level, write some string processing, communications
> >parsing, sequencing with multiple possible sequences, historical
> >logging, advanced process control, and operator interface routines in
> >it.

> The fact that you can't do this in Ladder Logic is precisely what
> makes it a "higher-level" language.

You can do it, by the Church-Turing thesis; it's just a lot of pain, especially since you don't get any code reuse. (No functions, no code
reuse.) So you'd end up writing a lot of very repetitive code.

In reality, you'd probably write yourself a higher-level language that compiles into ladder if you actually had to do that.

> Yes, your calculator is "higher-level" than your PC, precisely because
> it limits your functionality and in doing so makes it very, very easy
> to use.

That has nothing to do with higher or lower level.

> I do see your point. For example, Java, as a programming language, is
> far more powerful and flexible than Ladder Logic and is generally
> considered a "high-level" language. So if Ladder is so limited, how
> can it be high-level?

It isn't. The reason Java is considered high-level isn't because it has a large library available, but because it has the concept of libraries, and functions, and objects, and local variables, and so on.

In Java, you could write an AirCylinder object that would handle all the standard things with air cylinders, and then use it for every cylinder in the machine, and the whole factory. In LL, for every cylinder you have to manually allocate the timeout timers and repeat the logic for "if the extended sensor doesn't come on within so many seconds, trip an alarm".


> Thanks, T. Connolly, for providing the answer:

> >Please don't confuse the availabilty of a large library of functions
> >(such as in C) for a language level

> Remember, in C you can't even put output on the screen without a
> library!

Well, LL doesn't even have the concept of a library (or, for that matter, even a function), so that's that.

> (C++ takes care of this).

FWIW, no (it's also in the library).

> Ladder is the same way; there ARE PLC's that can manipulate strings,
> have user-defined functions, and have large libraries.

I've never seen this done in a way that wouldn't be severely tacked-on; but yeah, if it can do those things (user-defined functions, libraries) then it's somewhat higher level, depending on the extent to which it does them.

> Also, to Vladimir Zyubin's point:
> >It is impossible (in practice) to write a C compiler in the machine
> >codes... directly... by "0"s and "1"s... And you could write a
> >machine codes interpreter in C. So, do you think machine-codes is a
> >high level languages?

> It is impossible in practice to do ANYTHING in machine codes. This is
> not really a programming language.

It satisfies the definition.

...
> But obviously, machine-codes is as low as you get.

Yup.

> On the issue of credibility: I am NOT a computer scientist. I am a
> Software Engineer, which is accurately described as "applications
> programmer." Many computer scientist don't write any actualy code
> ever.

Well, I've written code; you can even look at some of it if you like.

> So any profs out there who want to take me to town, so be it. But I
> stick by my definitions, while acknowledging that this is not a
> cut-and-dried proposition.

It is cut-and-dried, at least in the broad outline. You'd be hard-pressed to invent a more low-level language for bit logic without actually going to machine-codes-equivalent.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
J

James Ingraham

Thanks, Dan Pierson!

I think that was a very eloquent description.

Am I wrong in saying that perhaps we've all been crazy to try an shoe-horn ladder logic into the discussion? Also, I'm curious what you would say about flow-charting systems like Think & Do.

-James Ingraham
Sage Automation, Inc.

 
T
It seems to me the underlying debate here is really what "low level" and "high level" means. Settle that and then whether or not LL is high level or low level will be apparent to all.

I stand by my general definitions:
Low level = work.
High level = less work (because someone else previously put in a lot of work)

High level is generally more rigid because the programmers that write the compiler/interpreter cannot anticipate all possible uses for the language so some language grammer, naming rules, and data typing are imposed so that the compiler can determine what the programmer's intent is with a degree of precision.

Language sophistication does not equal language level. C is a very unsophisticated language. Take away the libraries and your not left with much.

The more a language takes care of basic work for the programmer when instructing the hardware what to do, then the higher it rises above the low language level, sometimes at the cost of flexibility.

Inflexibility does not mean limitations. I once lived in Korea for a period of time during my teens. I learned a little Korean, and sometimes my sentences were twice as long as someone fluent in the language, but I was able to say what I needed. The point is that my grasp of the language made my communicaitons somewhat inflexible, but not necessarily limited in what I could eventually communicate.

If you could program a controller by talking to it in plain english you would have to stick to some very strict grammer rules. If your processor doesn't know a particular word you would have to use a series of other words. Your program would become very verbose. Then someone will come along and tell you to talk in C because
its better. You'll never reach an agreement with them.
 
G

George Robertson

You've hit the biggest nail on the head here. Is ladder really easier? For an electrician, yes. For other people, no. Hence someone replacing
hardwired relay ladder logic with a PLC finds the language to be well suited and "high level" by the definition of ease of use. Of course, the
front panel of my Microwave at home would then be a "high level" language (while the VCR, of course, would be very low.) Someone unfamiliar with relay logic, might not find ladder to be so simple. They might find BASIC to be a higher level language.

My original post dealt with abstraction from the machine, although I did not put it so eloquently as subsequent posters to this list. I still stand by RLL have a low level of abstraction from the machine, and being only slight higher level than assembler.

A free online dictionary of computing defines languages by the number of machine language instructions represented by each instruction in the language. Hence assembly is a first generation language, and the elusive AI is a fifth generation language.

I'm not sure I'm comfortable with this definition alone, however. It would imply that my optimizing compiler reduces the level of my source
code.

BTW, whatever happened to that poor chap who originally asked about FORTRAN on his PLC?

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
[email protected]
(915) 366-4252
 
M

Michel A. Levesque, eng.

Talk about opening a can of worms! Obviously the definition of a low level or high level language is kinda all over the place. So here goes the definitions going from low level (machine)to high level (fully abstracted):
1. machine code (1 or 0 in a 8,16 ,32, 64 or 128 bit grouping)
2. Pseudo code, also know as assembler (16 or 32 bit pattern for a given pseudo code (or assembly instruction).
3. compiled mid language such as C, C++. You can insert assembly as inline code in C and you need libraries for anything, and supports cross platform coding.
4. compiled high level such as FORTRAN, Cobol, or any Visual xxx stuff (cannot insert inline assembly code without setting up a framework, cross platform support is not a bed of roses).
5. interpreted languages (cannot run without a supporting infrastructure). You could put the Visual xxx stuff here since you need the support of the Windows environment.

Usually if a language instruction correlates directly with a machine code bit pattern it is low level. If a language instruction correlates to a set of bit patterns or has no correlation whatsoever (APL anyone), then it is of a higher level.

Ladder is a lot like Pseudo code, one ladder instruction is a defined bit pattern for the processor.
 
T
> Ladder is a lot like Pseudo code, one ladder
> instruction is a defined bit pattern for the
> processor.

- actually, ladder is an interpreted language, often compiled to a pcode series of hex numbers to save memory, but then interpreted by the PLC. It does not compile to machine language to be executed directly on the processor. The interpreter takes care a great deal of work for the programmer.
 
V

Vladimir Zyubin

Hello List,

T. Connolly wrote:

>> Ladder is a lot like Pseudo code, one ladder instruction is a defined
>> bit pattern for the processor.
>
> - actually, ladder is an interpreted language,
[...]

wrong statement...
Interpreter - it is a kind of translaters (not of languages!)... Quite possible some ladder translators have the compiler form... As well as there are C-interpreters.

Have a look at the yahoo.com results on "C language interpereter"

for example:
====
EiC Home Page
... EiC is a freely available C language interpreter in both source and binary
form.
EiC allows you to write C programs, and then "execute" them as if they were a ...
http://www.kd-dev.com/~eic/
====

--
Best regards,
Vladimir mailto:[email protected]
 
Top