From: | Kaz Kylheku <157-073-9834@kylheku.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 10 Apr 2018 18:38:52 +0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | 18-04-029 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="61525"; mail-complaints-to="abuse@iecc.com" |
Keywords: | C, design |
Posted-Date: | 11 Apr 2018 13:22:57 EDT |
On 2018-04-10, Martin Ward <martin@gkc.org.uk> wrote:
> Yet, for all that complexity, "C combines the power of assembly language
> with the flexibility of assembley language"!
Not so; C provides no portable way to inspect the stack or machine
registers. Writing a precisely-tracing garbage collector which can
look for root pointers in the stack is possible in assembly language;
only a conservative approach is feasible in anything remotely resembling
portable C.
Assembly languages are predictable; for instance, they have defined
behaviors on integer overflow.
Decent quality instruction sets architectures provide ways to catch
an exception in a handler which can precisely re-start the program from
the faulting point after doing some fixup. Almost anything can be
treated in a way that assures safety: illegal instruction, division by zero.
In assembly languages, a pointer value held in a register doesn't become
"indeterminate" just because it was passed to some free()-like function.
(And other such nonsense fictions.)
Return to the
comp.compilers page.
Search the
comp.compilers archives again.