Re: [Tinycc-devel] read32le/write32le

[David Mertens]

Cool. I'm more of a tcc user than a compiler hacker, so your answers have made me happy. Looking over the patch, I would say that it *looks* fine, so if we get better behavior with no noticeable slowdowns, it's a good patch.

I am far from an authority, though. Anybody else care to comment?

David

On Wed, Nov 18, 2015 at 3:28 PM, Edmund Grimley Evans <address@hidden> wrote:

> As I understand it, this patch changes certain bit copying lines. Those which
> cast their data as integer arrays are now cast as character arrays, and what
> used to be a single copy operation is now four copy operations. Presumably this
> would lead to behavior that is more robust and less likely to fail. Can you
> explain under which circumstances the integer copy would fail where the
> character copy would succeed?

The "*(int *)ptr += ..." stuff could fail in several circumstances:

- host is not little-endian
- host does not allow unaligned memory access
- compiler does some bizarre optimisation because of the implication
  that ptr must, somehow, be a valid pointer to int

> Also, can we expect smart compilers to notice
> that we're copying four consecutive bytes, and use a 32 bit read/write instead
> of four 8 bit read/writes?

Yes.

> In short: it seems unlikely to me that we'd get wrong behavior on any platform
> used by TCC using the current code. Thus a good explanation, and benchmarks
> showing minimal (or zero) impact on execution are important for this patch.

I found no measurable slow-down of tcc built by tcc building tcc.

Edmund

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan