On C/C++ undefined behaviours

[Don]

Nick Sabalausky wrote:
> "SK" <sk at metrokings.com> wrote in message 
> news:mailman.448.1282374566.13841.digitalmars-d at puremagic.com...
>> On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>> SK wrote:
>>>> I love open source projects, but off the top of my head here are some
>>>> reasons that's not a general substitute for TIMI for D:
>>>> 1) What about closed source software?
>>> Won't work anyway. Java bytecodes are trivially turned back into source.
>> IMO, reverse engineering technology is not the issue.
>>
> 
> The *whole point* of closed-source is that the source isn't available. If 
> Java bytecode is trivially turned back into meaningful source, then 
> closed-source Java ain't closed-source anyway.
> 
>>>> 2) From-source builds may be more complex or resource consuming than
>>>> could be accommodated on the machine the customer used to launch, e.g.
>>>> a hand-held device.
>>> I've worked on a Java VM enough to know that won't be a problem.
>>>
>> Why waste your batteries running deep and complex front-end optimizers
>> that have nothing to do with the target platform?
>>
> 
> The compiler's not going to do any deep analysis of code that's versioned 
> out for a different platform. Just lexing, maybe parsing, and that's it. 

It should do more than that. But...

> AIUI, the real battery-eating processing is elsewhere, mainly in stuff 
> that's also going to be done by any decent JIT engine. (Not that there 
> wouldn't be at least *some* saved cycles.)

this is probably correct: it's the optimisation steps that burn the most 
cycles.
Personally I think the most interesting platform-dependent stuff happens 
in the front-end. That's the only place you can change algorithms based 
on the platform, and algorithmic changes are where the big gains are. 
And most of the advocacy literature for JIT compilation seems oblivious 
to that fact. You can do some really nice stuff if you compile at 
install time.