ken@gatech.edu (Ken Seefried iii) (08/23/88)
--
It is my understanding that PL/M is (or was) the system programming language
of choice for the iAPX processors.
Can someone offer critical commentary as to the suitibility of PL/M as
ssystem programming language over, say, C?
What makes PL/M uniquely suited to programming the iAPX processors?
Thanks...
ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs,
ken@gatech.edu inhp4, masscomp, rlgvax, sb1, uf-cgrl,
ccastks@gitvm1.bitnet unmvax, ut-ngp, ut-sally}!gatech!kenjohn@jetson.UPMA.MD.US (John Owens) (08/24/88)
In article <17377@gatech.edu>, ken@gatech.edu (Ken Seefried iii) writes: > It is my understanding that PL/M is (or was) the system programming language > of choice for the iAPX processors. No, it's the systems programming language pushed by Intel for the iAPX processors. > Can someone offer critical commentary as to the suitibility of PL/M as > ssystem programming language over, say, C? No, but if I had time, I'd give some for in the other direction. > What makes PL/M uniquely suited to programming the iAPX processors? Nothing, except that Intel designed it and had compilers for it long before they bought someone else's C compiler to use as "Intel C". Don't forget compatibility with PL/M-80! -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)
rgc@edison.GE.COM (Rick) (08/24/88)
In article <17377@gatech.edu>, ken@gatech.edu (Ken Seefried iii) writes: > -- > > It is my understanding that PL/M is (or was) the system programming language > of choice for the iAPX processors. > I thought that Intel pushed this high-level language on the software developers...as if there were no other languages available for their processors??? > Can someone offer critical commentary as to the suitibility of PL/M as > ssystem programming language over, say, C? > There are no suitable comparisons of PL/M to C...there is no contest (in favor of C)... > What makes PL/M uniquely suited to programming the iAPX processors? > Intel did make some optimum hooks and handles in PL/M that were suitable towards their processors (ie, a SEG and OFFSET function). They also had 3 levels of code optimization (before anyone else had??) ... 'course almost all compilers now offer some types of optimization, don't they :-) > Thanks... Overall, i prefer using C (and some assembly, if necessary) with the Intel processors... -- Yet another comment from: ------------------------ Rick Carl rgc@edison.GE.COM
don@seila.UUCP (Don Kossman) (08/25/88)
In article <17377@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: >It is my understanding that PL/M is (or was) the system programming language >of choice for the iAPX processors. > >Can someone offer critical commentary as to the suitibility of PL/M as >system programming language over, say, C? i've used both PL/M and C to do system programming directly on Intel iron and using iRMX-[2]86. There is absolutely NO reason to use PL/M; it just happens to have been the first language beyond asm86 that Intel developed. It's got a few built-ins to handle segment descriptors, I/O registers, and interrupt procedures, but these may be easily constructed in assembler in a few hours and may then be forgotten. It may also still be true that Intel only provides complete iRMX interface libraries for PL/M; again, it is simple to write the required assembler routines and then do everything in C. (I probably still have these around, let me know if you need them). PL/M has rotten floating point support, and NO I/O or function libraries comparable to stdio and the other standard C libraries. (imagine life without printf...) In addition, it has a verbose syntax compared to C, no "default" in the switch/case statement, no break or continue constructs, and numerous other irritating properties. The only advantage it used to have was stronger typechecking of function parameters, but ansi C fixes that. To top it off, there is no string type; strings must be treated as arrays of bytes and are not null-terminated. This is a complete pain in the you-know-what. C is far and away a better choice. -- Don Kossman, SEI Information Technology, Los Angeles usenet: ...sun!tsunami!seila!don, ...uunet!mahendo!jplgodo!seila!don
tneff@dasys1.UUCP (Tom Neff) (08/30/88)
Intel's PL/M-86 (-286, etc) is a very good, meat and potatoes language for "pure" systems programming on iAPX class processors. I have used it extensively in dedicated target systems for six or seven years. What it lets you do is program right down to the iron (including interrupt handlers and time critical OS components) in a high level, procedural language, instead of having to do the "gut work" in assembler. As other posters have pointed out, it has no runtime library at all. This is entirely intentional, and often essential when you are doing my type of application. In terms of the power of the language, I could theoretically use C for most of what I do, but three factors have militated against it: (a) C doesn't normally give you the kinds of 86 hardware primitives (inline) you need to get time critical stuff done; (b) almost every implementation saddles you with a runtime library which you may or may not be able to ROM and run reentrant; and (c) Intel's own pathetic excuse for a C compiler -- adapted from an early version of Mark Williams C -- is a total abortion nobody could use for real work. (Nowadays Microsoft C does a good code generation job, but it doesn't write vanilla OMF object records I can link into my system. Intel is planning to ditch MWC completely and replace it with their own C compiler built around the excellent PL/M code generator, but that will Take a While.) Now, if the way you plan to use "iAPX processors" is to sit and write little programs on an IBM PC, I wouldn't recommend bothering with any of the Intel language products, including PLMx86. Instead you need Turbo C, Prolog etc. But in the event that your department wants to do A/D sampling or other such realtime work using Intel processors, I suspect PL/M would be a good, maintainable choice for the project. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
jbn@glacier.STANFORD.EDU (John B. Nagle) (08/31/88)
Much to my suprise, JPI TopSpeed Modula-2 turns out to be an adequate
system for low-level development. It generates ROMable code, the utilities
for organizing code and data spaces are provided, very little run-time
system is included implicitly (and due to a clever linker, none is included
without need), and library source is available. The compiler can generate
an interrupt routine in-line, with no need for an assembler low-level
interrupt routine. The downside is that the documentation for use in embedded
applications is inadequate and some modifications to the run-time startup
routine are needed to make it work in that environment.
Unlike PL/M, JPI offers a modern working environment, generally
similar to the Borland Turbo line. But it's a serious compiler, and can
go head-to-head with C compilers on some benchmarks. Modula-2, of course,
is a much less error-prone language than C, which is of real value when the
target environment is hostile and debugging facilities are weak. As is
typical with Modula, a high percentage of errors are caught at compile time.
I find that most of my programs run when first downloaded to the target.
John Nagleraymond@pioneer.arc.nasa.gov.arpa (Eric Raymond RIA) (09/01/88)
In article <17669@glacier.STANFORD.EDU> jbn@glacier.UUCP writes: > > Unlike PL/M, JPI offers a modern working environment, generally >similar to the Borland Turbo line. But it's a serious compiler, and can That's because the program is the remains of Borland's Turbo Modula-2 project (scrapped when Turbo C got off the ground).
blackman@eniac.seas.upenn.edu (David Blackman) (09/03/88)
I would like to point out one feature in PL/M-86 which makes it better suited for iAPX processors than most other languages - that is the SELECTOR data type. A SELECTOR is just a (16 bit) data type which is used like a pointer. Of course, a 16 bit pointer is not sufficient to address the full 8086 address space. To use SELECTORs, you use the convention that all SELECTOR-referenced objects are allocated on paragraph boundaries. Such a convention is used in iRMX-86. Under such an allocation convention, the SELECTOR will be the segment of the object's address; the offset of the object's address will be 0. SELECTORs don't help you out much with objects in the data or stack segments. You usually use them to reference objects which are dynamically allocated out of a heap. The advantages of SELECTORs include: 1. you can pass addresses around using a 16 bit SELECTOR rather than a full 32 bit POINTER. Structures containing pointers (linked lists, trees, etc.) shrink. 2. forming effective addresses for array elements or record fields is simplified. You just use the SELECTOR as the segment. The array index or record field displacement is used directly as the offset. 3. The scheme would be compatible with the 286 protection scheme. You gain per-segment protection on each reference to data. 4. Pointers can be ambiguous - are the addresses 0:100 and 10:0 "equal"? SELECTORs are unique. David
tneff@dasys1.UUCP (Tom Neff) (09/06/88)
David Blackman mentioned the SELECTOR data type and how useful it is. One of the things I like about PL/M is that you can BASE variables on any of three data types: POINTER, SELECTOR or WORD. BASED POINTER assumes full 32-bit indirect reference (except for $SMALL model which behaves differently in many ways), BASED SELECTOR assumes the variable lies at offset:0000 in the paragraph pointed to by the SELECTOR base, and BASED WORD assumes the variable lies in your current data segment, at the offset pointed to by the WORD variable. Hours of family fun. Oh, and last time I forgot to mention the other neat thing PL/M provides: Extended Segmentation models of compilation. Lets you divide a system into subsystems, each of which communicates within itself via 16-bit references between separately compiled modules, while "exported" references across subsystems are full 32 bit. Very sophisticated, you normally need assembler to do something like that. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)