Re: Optimization techniques

0xe2.0x9a.0x9b@gmail.com
Sat, 27 Apr 2019 04:56:45 -0700 (PDT)

          From comp.compilers

Related articles
[20 earlier articles]
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-26)
Re: Optimization techniques alexfrunews@gmail.com (2019-04-26)
Re: Optimization techniques derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2019-04-26)
Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-26)
Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-04-26)
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-26)
Re: Optimization techniques 0xe2.0x9a.0x9b@gmail.com (2019-04-27)
Re: Optimization techniques haberg-news@telia.com (Hans Aberg) (2019-04-27)
Re: C language andOptimization techniques alexfrunews@gmail.com (2019-04-27)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-28)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-28)
Re: Optimization techniques genew@telus.net (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques genew@telus.net (Gene Wirchenko) (2019-04-30)
[8 later articles]
| List of all articles for this month |

From: 0xe2.0x9a.0x9b@gmail.com
Newsgroups: comp.compilers
Date: Sat, 27 Apr 2019 04:56:45 -0700 (PDT)
Organization: Compilers Central
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-020 19-04-025
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="89966"; mail-complaints-to="abuse@iecc.com"
Keywords: performance, debug
Posted-Date: 27 Apr 2019 10:19:32 EDT
In-Reply-To: 19-04-025

On Friday, April 26, 2019 at 9:11:46 PM UTC+2, alexf...@gmail.com wrote:
> In this day and age it is a shame that the language [C] that is still very
> much alive does not provide the programmer with easy-to-use (and
> implement!) tools to perform/handle:
>
> - overflow checks like the above for +, -, *, /,
> %, <<, both signed and unsigned
> - mathematically meaningful comparison of signed
> and unsigned integers
> - arithmetic right shift out of the box
> - ditto rotation
> - arbitrary precision arithmetic (for integers
> of compile-time-constant length)
> - endianness at last
> - (I probably forget many more)


Hi. In my opinion, the C extensions you are requesting would just turn C into
C++ which allows the programmer to create a new class/struct and overload the
arithmetic operators.


> Often times the desired functionality is already in the CPU


With a Turing-complete CPU, any desired functionality is already in the CPU.


The only distinctions between Turing-complete CPUs are: performance, distance
to solutions (aka programming convenience).


> or needs
> just a few more instructions but there's no simple, short and standard
> way to tell the compiler to generate the code for the common problem.
> It's always compiler extensions (or dependencies on specific
> compilers), #ifdefs, inline (and non-inline) assembly, code like shown
> above, reinvented wheels all the way, over and over again, from
> project to project. I understand that C is minimalistic, but I think
> it needs to step up a bit.
>
> When I'm handling arbitrary, potentially maliciously crafted data, I
> want to have those overflow checks, but I don't want to be burdened
> with what the compiler can easily do for me but fails to deliver year
> after year just because it's not in the language.
>
> What may have been deemed sufficient back in the 80's is no more.
> Because the Internet. Deprecating gets() is nice but doesn't quite
> cut it.
>
> Alex


I don't fully understand. Are you suggesting to add buffer overflow checks to
the C language? When developing a C compiler, clearly it *is* possible to
transparently add those checks to C when the compilation target is something
like a virtual machine, the compiler&runtime just need to know which functions
are allocating and freeing memory.


Performance of the code generated by the compiler you seem to be requesting
depends on the choice of the physical representation of C pointers. The C
compiler can generate code performing buffer overflow checks even if pointer
size is unchanged from the traditional 4 or 8 bytes.


When calling assembly code from C, the C compiler can run the assembly code in
a virtual machine and thus can perform safety checks in a lot of cases. This
is clearly possible to implement, and the only factor here is performance.


Summary: If sacrificing performance is OK, it is possible to transparently
implement any imaginable kind of a safety measure.


Sincerely
Jan


Post a followup to this message

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