27 Feb
2015
27 Feb
'15
10:30 a.m.
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:
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. ;-)
TTFN - Guy
C does support bitfields, but can't take the
address of one. The latter is a
fairly uncommon requirement though, and so algorithms that require it will have
to roll their own using mask and shift operations. Given that x86 doesn't have
bitfield instructions and has to fake it with mask and shift, this is no great
loss in practice. It wouldn't surprise me if there was a bitfield_ptr<> in
Boost which did this.
Well, the 386+ CPUs have bit manipulation instructions and *almost* had bit string/field
instructions. There are still books out there that describe in detail the function of the
BFxxx instructions.
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.
It seems to me to be very strange that today we're coding in a language that was
developed for a PDP-11 minicomputer.