On Friday, 17 October 2014 at 16:26:08 UTC, ketmar via
Digitalmars-d wrote:
i have nothing against this either. but i have alot against
"integral with arbitrary size" type.
Actually it makes a lot of sense to be able to reuse 16-bit
library code on a 24-bit ALU. Like for loading a sound at 16-bit
then process it at 24-bit.
nope. if int is 32 but, and it's behavior is defined as 2's
complement
32-bit value, it doesn't matter what register size HW has. it's
compiler task to make this int behave right.
And that will result in slow code.
Then again, that makes you a very careful programmer ;)
that almost turned me to serial killer.
Yeah, IIRC I "cracked" it and put it on a diskette after a while…
i don't buying that "we'll made that pretty soon" PR. first
they making
it widespreaded, then i'll start caring, not vice versa.
C++ has a workgroup on transactional memory with expertise… So,
how long can you wait with planning for the future before being
hit by the train?
You need to be ahead of the big mover if you want to gain
positions in multi-threading (which is the most important area
that is up for grabs in system level programming these days).
this is a misconception. "low level language" is not one that
pleases
CPU down to bits and registers, it's about *conceptions*.
for example, good high-level language doesn't need pointers, yet
low-level one needs 'em.
Bad example. Low level languages need pointers because the
hardware use 'em. If you have a non-standard memory model you
need deal with different aspects of pointers too (like segments
or bank switching).
If you cannot efficiently compute existing libraries on 24-bit,
48-bit or 64-bit ALUs then the programming language is tied to a
specific CPU. That is not good and it will have problems being
viewed as a general system level programming language.
A system level language should not force you to be overly
abstract in a manner that affects performance or restricts
flexibility.
