On Feb 27, 2015, at 12:30 PM, Guy Sotomayor <ggs at
shiresoft.com> wrote:
> On Feb 27, 2015, at 10:27 AM, Chuck Guzis <cclist at sydex.com> wrote:
>
> On 02/27/2015 06:29 AM, Peter Corlett wrote:
>
>
>> C does support bitfields, but can't take the address of one.
True. Personally, I always found bitfields a bit cumbersome.
>
> I suppose that it's unreasonable for a language to support processor instruction
set extensions. But APL does a great job of supporting vectors; has a syntax for things
such as dot-product, etc. So it can't be that K&R weren't aware of such
things.
APL was very interesting, but every implementation I ever used was interpreted, not
compiled. It made for some pretty slow running code, even though development was very
fast for some things.
In a slightly perverse way, kind of like perl today :-)
It seems to me to be very strange that today we're coding in a language that was
developed for a PDP-11 minicomputer.
The frustrating thing for me is not just the instructions but the memory model. Some of
the issues (security springs to mind) that
we're facing today can be solved by *not* having a completely flat memory model.
I'm still a fan of tagged memory. ;-)
I'm not convinced that C can't handle tagged memory, but in any case, if what you
need is real metal-level speed, well written C is very hard to beat. The ability to
include assembler is also occasionally useful :-)
TTFN - Guy