Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.sys.intel
Subject: Re: PLM vs. C for 80286/80386
Keywords: PLM C
Message-ID: <4412@ficc.uu.net>
Date: 6 Jun 89 11:26:45 GMT
References: <598@philtis.UUCP> <14381@bfmny0.UUCP>
Organization: Xenix Support
Lines: 29

In article <14381@bfmny0.UUCP>, tneff@bfmny0.UUCP (Tom Neff) writes:
> CASETBL[BX]. C on the other hand does 'switch' as a full 
> if-then/elseif-then/elseif-then... series.

This must be something specific to intel's C/386, because traditionally
'C' compilers have used a variety of techniques to implement case...
including a jump table for dense case tables (such as PL/M DO CASE
constructs), lookup tables, if-then-else chains, and a combination of
all three. This optimisation existed even in Ritchie's V6 compiler.

> If your memory model needs are exotic or complex PL/M may be the only
> way to get it (besides ASMx86).  Its extended segmentation models are
> impressively flexible.  Intel C has four basic memory models and
> a "far" keyword but doesn't support extended segmentation.

At Ensun, we had a complete polled multitasker written entirely in PL/M.
If we had done it in C there would have had to be some assembly code to
handle the coroutine switching.

(Now is this a balanced article or what?)

If you're married to intel, go for PL/M by all means. If you don't want to
be tied to one processor family, go for C. If you work for the DoD, you didn't
read this far because you're using ADA :->.
-- 
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.