Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #2216

Re: Optimization techniques

From 0xe2.0x9a.0x9b@gmail.com
Newsgroups comp.compilers
Subject Re: Optimization techniques
Date 2019-04-27 04:56 -0700
Organization Compilers Central
Message-ID <19-04-032@comp.compilers> (permalink)
References <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-020@comp.compilers> <19-04-025@comp.compilers>

Show all headers | View raw


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

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-25 16:46 +0100
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-25 23:01 +0000
  Re: Optimization techniques alexfrunews@gmail.com - 2019-04-26 01:33 -0700
    Re: language design and Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-27 11:56 +0100
    Re: Optimization techniques 0xe2.0x9a.0x9b@gmail.com - 2019-04-27 04:56 -0700
      Re: C language andOptimization techniques alexfrunews@gmail.com - 2019-04-27 19:47 -0700
    Re: reliability features and Optimization techniques Bart <bc@freeuk.com> - 2019-04-28 11:58 +0100
      Re: reliability features and Optimization techniques Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-04-29 04:33 -0700
    Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:11 -0700
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-07 16:43 +0200
  Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-27 23:01 +0200
    Re: Optimization techniques, C++ numeric representations David Brown <david.brown@hesbynett.no> - 2019-04-29 17:24 +0200
      Re: Optimization techniques, C++ numeric representations Hans Aberg <haberg-news@telia.com> - 2019-04-30 15:01 +0200

csiph-web