inst182@tuvie (Inst.f.Techn.Informatik) (05/26/89)
I am carrying out some research on programming languages for hard real-time systems. The emphasis lies on the timing behaviour. The nature of hard real-time systems dictates, that the execution times of the application tasks is known (or bounded) in advance. My main interest is: How do different realtime languages try to achieve that an upper bound on the execution time is derivable. Please note, that I am interested in references to research projects, not in (commercialy) available programming environments. Therefore availability of compilers for the language is not an issue. Please mail references, names of projects (languages) etc. to my address shown *below* (Not the same as in the header). When I get enough replies I will post a summary. ********************************************************************** -alex (Alexander Vrchoticky) * Writing thesis at (not speaking for) alex@honey.at * Technical University Vienna honey!alex@uunet.UU.NET * (when I grow up I'll be a graduate) **********************************************************************
jmt@apple.com (Michael Tindell) (05/27/89)
In article <699@tuvie> inst182@tuvie (Inst.f.Techn.Informatik) writes: > My main interest is: How do different realtime languages > try to achieve that an upper bound on the execution time is derivable. > Please note, that I am interested in references to research projects, not > in (commercialy) available programming environments. Therefore I AM interested in commercially available environments, as well as current research with langauge constructs for representing time and resource constraints in hard real-time systems. Any information and/or pointers greatly appreciated - thanks. You can never tell...
tneff@bfmny0.UUCP (Tom Neff) (05/27/89)
In article <2100@internal.Apple.COM> jmt@apple.com (Michael Tindell) writes: >I AM interested in commercially available environments, as well >as current research with langauge constructs for representing >time and resource constraints in hard real-time systems. Any >information and/or pointers greatly appreciated - thanks. I am posting this via Followup rather than mail because it's time PL/M raised its head in comp.realtime. I recommend PL/M as a realtime language of choice in all Intel CPU environments from 8051 to 80486. Its code generation is a carefully known thing, very efficient and close to the hardware yet allowing full HLL manipulation and modular development. It doesn't get the glamorous press romancing that Turbo Blah and Quick-Burp and such get, but PL/M is a marvel to behold. The good news for C-philes is that the new Intel C is a complete rewrite with a dpANSI compatible front end and the SAME PL/M code generator as a back end. So you can write safe predictable realtime C and PL/M code both. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
knight@csli.Stanford.EDU (Bob Knight) (05/28/89)
In article <14355@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >I am posting this via Followup rather than mail because it's time >PL/M raised its head in comp.realtime. I recommend PL/M as a realtime >language of choice in all Intel CPU environments from 8051 to 80486. I would agree, having written loads of PL/M code for 808x platforms, with one caveat --- if you want/need complex data structures, PL/M is not a good choice: creating an analogue to typedef is painful, one may not nest structures, and structures themselves are (grossly, in my opinion) limited as to the number of elements they may have. It's good to hear that Intel may have their C act together. Versions 3 and 4 of the compiler, from the brief look I took at them, were horrible losers. Now, if they could get a bit less pricey... Bob
tneff@bfmny0.UUCP (Tom Neff) (05/28/89)
In article <9142@csli.Stanford.EDU> knight@csli.stanford.edu (Bob Knight) writes: >In article <14355@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >> I recommend PL/M as a realtime >>language of choice in all Intel CPU environments from 8051 to 80486. > >I would agree, having written loads of PL/M code for 808x platforms, with >one caveat --- if you want/need complex data structures, PL/M is not a good >choice: creating an analogue to typedef is painful, one may not nest >structures, and structures themselves are (grossly, in my opinion) limited >as to the number of elements they may have. Actually as of PL/M 2.7 and later (currently at 3.1 so we're talking a couple of years) most of those limitations are gone. Structures can indeed be nested, and the number of elements is up, as are things like proc counts and LITERALLY lengths. A big improvement. I agree you don't have the flexibility of a C typedef, and occasionally it makes you have to think a bit harder, but my experience in realtime programming is that anytime things get more complex than what PL/M easily provides, you SHOULD be thinking harder! Like whether things need to be that complex for one thing... :-) The two reasons C is better for some of this systems work IMHO are pointer magic and the += -= *= /= &= |= ~= operators. Nothing I hate worse than having to write mystruct(ix*5-1).tag(iy+delta) = mystruct(ix*5-1).tag(iy+delta) + 1; However after working with PL/M for 7 years I know it backwards and forwards and therefore I *trust* it when the coding is tight and the consequences life-or-death. No frills but no surprises either. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
sccowan@watmsg.waterloo.edu (S. Crispin Cowan) (05/29/89)
In article <14355@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >In article <2100@internal.Apple.COM> jmt@apple.com (Michael Tindell) writes: [request for realtime HLL] >I am posting this via Followup rather than mail because it's time >PL/M raised its head in comp.realtime. I recommend PL/M as a realtime >language of choice in all Intel CPU environments from 8051 to 80486. I've had only one, brief, painful experience with PL/M, and I'd never touch it again. This is mostly because I'm a long-time C hacker, and where ever there was a design choice to be made, the PL/M creators seem to have gone out of there way to choose the OPPOSITE one that C did. I suppose that it's not that bad a programming language, but it made my brain HURT to try to write & debugg code using it. >-- >Tom Neff UUCP: ...!uunet!bfmny0!tneff > "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET Crispin ---------------------------------------------------------------------- Login name: sccowan In real life: S. Crispin Cowan Office: DC3548 x3934 Home phone: 570-2517 Post Awful: 60 Overlea Drive, Kitchener, N2M 1T1 UUCP: watmath!watmsg!sccowan Domain: sccowan@watmsg.waterloo.edu "Everything to excess. Moderation is for monks." -Lazarus Long
tneff@bfmny0.UUCP (Tom Neff) (05/30/89)
In article <26614@watmath.waterloo.edu> sccowan@watmsg.waterloo.edu (S. Crispin Cowan) writes: >I've had only one, brief, painful experience with PL/M, and I'd never >touch it again. This is mostly because I'm a long-time C hacker, and >where ever there was a design choice to be made, the PL/M creators >seem to have gone out of there way to choose the OPPOSITE one that C >did. I suppose that it's not that bad a programming language, but it >made my brain HURT to try to write & debugg code using it. PL/M wasn't really designed in the sense Crispin means. Its syntax was adapted from PL/I Subset which was an afterthought to IBM's PL/I (born at the 1967 Vienna Conference as PL/C), i.e., a classic ALGOL-derived block structured language. Subset was supposed to run on advanced state of the art computers like the 1130! that lacked the capacity for the huge gut busting formatted I/O packages that full PL/I wanted. It retained the block structure and the main data types. Digital (I believe) did the original adaptation for the 8080 in 1978 or 1979 and Intel OEM'd an early version and took it over, releasing their own for the 8086 in 1980 or 81. Since then it has kept pace with the evolving x86 architecture, expanding its data types and adding hardware builtins as needed. PL/M-486 should be out very shortly, I know Intel is using it internally. I can see where a dyed in the wool C hacker might balk at PL/M's heavily keyword oriented and Algolish feel, but IMHO no true systems person should be that much a slave of one language. I have lived through everything from FORTRAN II to BLISS to C to FORTH to PL/M to Apple Integer Basic and many more, and I like to tell myself I will be there typin' away when the NEXT revolution rolls around. Just give me a terminal and a deadline... :-) -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
raveling@venera.isi.edu (Paul Raveling) (05/31/89)
I'll semi-second nomination of PL/M as a good real time language for 8x86 family processors. This is based on some avionics software that I worked on that had critical real time requirements. Each of several air data computers used a mix of PL/M-86 and 8086 assembly language, mixed in proportions of about 70/30 to 50/50. These applications needed speed and didn't need more than basic language features. Typical PL/M-86 logic was around a factor of 2 slower than typical hand-coded assembly language, which is pretty decent on Intel's PISC (Perverse Instruction Set Computer) architecture. Another might-have-been would be a variant of BLISS. The BLISS-11 compiler was the best I've seen so far at efficient code generation, and the language was almost the right blend of simplicity and capability. Some details of syntax were it's main problem -- probably the dilemma of "how many dots" was the biggest. ---------------- Paul Raveling Raveling@isi.edu
peter@ficc.uu.net (Peter da Silva) (05/31/89)
In article <14355@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > I am posting this via Followup rather than mail because it's time > PL/M raised its head in comp.realtime. I recommend PL/M as a realtime > language of choice in all Intel CPU environments from 8051 to 80486. That's the problem, though. You're stuck in intel environemnts once you're coding in PL/M. That's fine for embedded controllers, but for big projects it's a major cross to bear. PL/M is a nice little language, but it's too closely tied to the processor. If you've any intent of making your code portable, avoid it. If you're married to intel for other reasons, though, I can't think of a better language for their x86 family. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
paul@moncam.co.uk (Paul Hudson) (06/01/89)
In article <8524@venera.isi.edu>, raveling@venera.isi.edu (Paul Raveling) writes: > Another might-have-been would be a variant of BLISS. The .BLISS is .IGNORANCE Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket" -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"
cooper%vlab.dec.com@decwrl.dec.com (g.d.cooper in the shadowlands) (06/01/89)
In article <8524@venera.isi.edu>, raveling@venera.isi.edu (Paul Raveling) writes... > These applications needed speed and didn't need more than > basic language features. Typical PL/M-86 logic was around > a factor of 2 slower than typical hand-coded assembly language, > which is pretty decent on Intel's PISC (Perverse Instruction Set > Computer) architecture. While I agree that PL/M isn't as good as hand-coded assembler where else will you get the message (I wish I could remember the exact wording): ..Instruction optimized out of existence... Optimization for PL/M when I used it briefly (about '84 I think) ran from fair to excessive. At the top end I would expect better performance than a factor of 2 (excluding proc call overhead). > Another might-have-been would be a variant of BLISS. The > BLISS-11 compiler was the best I've seen so far at efficient > code generation, and the language was almost the right blend > of simplicity and capability. Some details of syntax were > it's main problem -- probably the dilemma of "how many dots" > was the biggest. Actually to get back to the original thrust of this thread, BLISS-10 could be very accurately predicted as to code size. Depending on the constructs, you could figure +/- 2 instructions as long as the code was not so convoluted as to give the optimizer time to play. ============================================================================ | But I that am not shaped for sport- | Geoffrey D. Cooper | | ive trick, nor formed to court an | cooper%vlab.dec.com@decwrl.dec.com | | amorous looking glass... | business (508) 467-3678 | | | home (617) 925-1099 | ============================================================================ Note: I don't work for DEC I'm a consultant. My opinions are just that. MINE!
loeffler@iravcl.ira.uka.de (06/02/89)
In article <14364@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes: > In article <26614@watmath.waterloo.edu> sccowan@watmsg.waterloo.edu (S. Crispin Cowan) writes: >>I've had only one, brief, painful experience with PL/M, and I'd never >>touch it again. This is mostly because I'm a long-time C hacker, and >>where ever there was a design choice to be made, the PL/M creators >>seem to have gone out of there way to choose the OPPOSITE one that C >>did. I suppose that it's not that bad a programming language, but it >>made my brain HURT to try to write & debugg code using it. > > PL/M wasn't really designed in the sense Crispin means. Its syntax was > adapted from PL/I Subset which was an afterthought to IBM's PL/I (born > at the 1967 Vienna Conference as PL/C), i.e., a classic ALGOL-derived > block structured language. Subset was supposed to run on advanced state > of the art computers like the 1130! that lacked the capacity for the huge > gut busting formatted I/O packages that full PL/I wanted. It retained the > block structure and the main data types. Digital (I believe) did the > original adaptation for the 8080 in 1978 or 1979 and Intel OEM'd an early > version and took it over, releasing their own for the 8086 in 1980 or 81. > Since then it has kept pace with the evolving x86 architecture, expanding > its data types and adding hardware builtins as needed. PL/M-486 should be > out very shortly, I know Intel is using it internally. > > I can see where a dyed in the wool C hacker might balk at PL/M's heavily > keyword oriented and Algolish feel, but IMHO no true systems person should > be that much a slave of one language. I have lived through everything from > FORTRAN II to BLISS to C to FORTH to PL/M to Apple Integer Basic and many > more, and I like to tell myself I will be there typin' away when the NEXT > revolution rolls around. Just give me a terminal and a deadline... :-) > -- > Tom Neff UUCP: ...!uunet!bfmny0!tneff
karl@ficc.uu.net (karl lehenbauer) (06/06/89)
If I may throw my $0.02 into the merits of PL/M, the 80286 PL/M generates excellent code under optimize 3, although it does occasionally misoptimize and produce bogus code (at level 3) :-( PL/M, as has been noted, locks one into Intel architectures, and it took Intel a rather long time to make the compiler available for the 386 as well. Tom Neff pointed out that as of PL/M 2.7 many limitations on structure nesting, number of elements, etc, have been removed or substantially reduced. This is a good thing, but the restrictions were a pain and there is a lot of existing code that was written, and kludged, because of the previous limitations. I think the most apalling thing about the language itself, and the part that has caused me the most personal grief, is that pointers don't have data types. Thus, a lot of improper use of pointers which would cause warnings (at least) from most C compilers are passed without comment by PL/M and one gets to find the problem by debugging. We do a lot of stuff that has to be FORTRAN-callable, and *all* the parameters for a PL/M routine that's FORTRAN- callable have to be pointers, so a lot of the benefits of data type checking by the compiler are lost to us. -- -- uunet!ficc!karl "Contemptuous lights flashed across the computer's -- karl@ficc.uu.net console." -- Hitchhiker's Guide