On 12/31/2012 10:47 PM, Marcus G. Daniels wrote:
On 12/31/12 8:30 PM, Paul D. Fernhout wrote:
So, I guess another meta-level bug in the Linux Kernel is that it is
written in C, which does not support certain complexity management
features, and there is no clear upgrade path from that because C++
has always had serious linking problems.
But the ABIs aren't specified in terms of language interfaces, they
are architecture-specific. POSIX kernel interfaces don't need C++
link level compatibility, or even extern "C" compatibility
interfaces. Similarly on the device side, that's packing command
blocks and such, byte by byte. Until a few years ago, GCC was the
only compiler ever used (or able) to compile the Linux kernel. It is
a feature that it all can be compiled with one open source toolchain.
Every aspect can be improved.
granted.
typically, the actual call into kernel-land is a target-specific glob of
ASM code, which may then be wrapped up to make all the various system calls.
as for ABIs a few things could help:
if the C++ ABI was defined *along with* the C ABI for a given target;
if the C++ compilers would use said ABI, rather than each rolling their own;
if the ABI were sufficiently general to be more useful to multiple
languages (besides just C and C++);
...
in this case, the C ABI could be considered a formal subset of the C++ ABI.
admittedly, if I could have my say, I would make some changes to the way
struct/class passing and returning is handled in SysV / AMD64. namely
make it less complicated/evil, like, say, the struct is either passed in
a single register, or passed as a reference (no decomposition and
passing via multiple registers).
more-so, probably also provide spill-space for arguments passed as
registers (more like in Win64).
granted, this itself may illustrate part of the problem:
with many of these ABIs, not everyone is happy, so there is a lot of
temptation for compiler vendors to go their own way (making going "mix
and match" with code compiled by different compilers, or sometimes with
different compiler options, unsafe...).
sometimes, it may usually work, but sometimes fail, due to minor ABI
differences.
From that thread I read that those in the Linus camp are fine with
abstraction, but it has to be their abstraction on their terms. An
later in the thread, Theodore T'so gave an example of opacity in the
programming model:
a = b + "/share/" + c + serial_num;
Arguing "where you can have absolutely no idea how many memory
allocations are
done, due to type coercions, overloaded operators"
Well, I'd say just write the code in concise notation. If there are
memory allocations they'll show up in valgrind runs, for example. Then
disassemble that function and understand what the memory allocations
actually are. If there is a better way to do it, then either change
abstractions, or improve the compiler to do it more efficiently.
Yes, there can be an investment in a lot of stuff. But just defining
any programming model with a non-obvious performance model as a bad
programming model is shortsighted advice, especially for developers
outside of the world of operating systems. That something is
non-obvious is not necessarily a bad thing. It just means a bit more
depth-first investigation. At least one can _learn_ something from
the diversion.
yep.
some of this is also a bit of a problem for many VM based languages,
which may, behind the scenes, chew through memory, while giving little
control of any of this to the programmer.
in my case, I have been left fighting performance in many areas with my
own language, admittedly because its present core VM design isn't
particularly high performance in some areas.
though, one can still be left looking at a sort of ugly wall:
the wall separating static and dynamic types.
dynamic types is a land of relative ease, but not particularly good
performance.
static types is a land of pain and implementation complexity, but also
better performance.
well, there is also the "fixnum issue", where a fixnum may be just
slightly smaller than an analogous native type (it is the curse of the
28-30 bit fixnum, or the 60-62 bit long-fixnum...).
this issue is annoying specifically because it specifically gets in the
way of having an efficient fixnum type and also map it to a sensible
native type (like "int") while keeping the usual definition intact that
"int" is exactly 32-bits and/or that "long" is exactly 64-bits.
but, as a recent attempt at trying to switch to untagged value types
revealed, even with an interpreter core that is "mostly statically
typed", making this switch may still open a "big can of worms" in some
other cases (because there are still "holes" in the static type-system).
I have been left considering the possibility of instead making a compromise:
"int", "float", and "double" can be represented directly;
"long", however, would (still) be handled as a boxed-value.
this should work ok mostly as "int", "float", and "double" are much more
common than "long", and at least being able to unbox 3 of them would be
good (as-is, I end up having to box all of them).
the trick here is mostly that this still allows for type-tags in the
references, but would likely involve a partial switch to the use of
64-bit tagged references within some core parts of the VM (as a partial
switch away from "magic pointers"). I am currently leaning towards
putting the tag in the high-order bits (to help reduce 64-bit arithmetic
ops on x86).
possible(high 4): 0/15=pointer, 1/2/13/14=fixnum, 3/4/11/12=flonum1,
5/10=flonum2,
6="spaces", 7=tag2, 8/9=resv
pointer: 60 bit object-pointer.
fixnum: 62 bit integer.
flonum1: double encoded directly (values where -256<exp<256 can be
encoded exactly)
flonum2: double with 3 bits shaved off.
tag2: 4/12/28-more tag bits, with 56/48/32-bit spaces.
"spaces": related to how tagged-values are implemented on x86-64 via the
"magic pointer" system, but is mostly N/A for x86.
possibly coded via tag2: int32 (sub-case), float32 (sub-case), char32, ...
note: this would be a mostly localized set of changes.
does sometimes seem like I am going in circles at times though...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
