Re: language design after Algol 60, was Add nested-function support

Kaz Kylheku <157-073-9834@kylheku.com>
Tue, 10 Apr 2018 18:38:52 +0000 (UTC)

          From comp.compilers

Related articles
[7 earlier articles]
Re: language design after Algol 60, was Add nested-function support martin@gkc.org.uk (Martin Ward) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (2018-04-10)
Re: language design after Algol 60, was Add nested-function support genew@telus.net (Gene Wirchenko) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support gneuner2@comcast.net (George Neuner) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support 157-073-9834@kylheku.com (Kaz Kylheku) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support 157-073-9834@kylheku.com (Kaz Kylheku) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-10)
Re: language design after Algol 60, was Add nested-function support DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2018-04-11)
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-11)
Re: language design after Algol 60, was Add nested-function support DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support bc@freeuk.com (bartc) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support rpw3@rpw3.org (2018-04-12)
[6 later articles]
| List of all articles for this month |
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.)


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.