Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: Android?Why Dalvik? Date: Mon, 30 May 2011 21:58:11 -0700 Organization: albasani.net Lines: 89 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 0LiMipd/+9lepaKMmrJC+imzlDBYTLG2R0pFjcE1+GnejTbeNy23hPyFyBvypsU9VPuTYefqGz5h1Mxz62EQOypT1anw/4hMZyNLgxJrZ4FqHgdJNEXb6NSHtU6wN76a NNTP-Posting-Date: Tue, 31 May 2011 05:01:21 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="JBocmBdcLJFr2h/ggXtbfAMmNgO0UXW4r3FmKPtEaLdRrdqK02T8OTLIYuY+r6at1/Imh/OGQXGSBTH7yJlq4ZKmfEyYMOvOrxYn7ygfMKxXuNaEiN5wO1FjQ43K9pc3"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:6Jo3V5FpGtoL1xahWjWtrJWTo84= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4788 On 5/30/2011 7:12 PM, Steve Sobol wrote: > In article, BGB says... > >>> I'd bet, these days, that the root cause of that situation is the > fact >>> that the three operating systems have *completely* different GUI's. >>> >> >> for source compatibility, yes, cross-platform GUI is a big issue. >> >> >> for binary compatibility, the much bigger issue is the lack of a common >> set of binary formats, as well as different CPU architectures and >> operating modes. > > > CPU architectures aren't really a major issue anymore. Linux, many > BSDish operating systems, OS X and Windows all run primarily on Intel > CPUs. > yes, but at the moment there are 2 partly incompatible operating modes: 32 and 64 bit mode... also, I prefer to say x86 CPUs, rather than Intel CPUs, since Intel is a particular company and not the sole supplier of x86 chips... hence, calling them Intel CPUs sort of discriminates against everyone who uses AMD and VIA chips. > However, you are right about executable formats. It would be less of an > issue if OS X supported the Linux ELF format. FreeBSD is able to use ELF > executables, but ELF is not that OS's native binary format. > or, everyone could use PE/COFF... well, other relevant issues: ABI differences; different system libraries; ... >> my ideas for running C in a bytecoded VM, also just happened to > include >> ways of basically delaying final type specialization, many cases of >> handling "#ifdef" blocks, ... until JIT time. > > But to me, that eliminates *the biggest* benefit to using C (and dealing > with its hassles). > in which way in particular?... much application code wouldn't likely notice much difference, and in many cases, early type-handling and doing preprocessor magic could still be done early (at compile time). if the post-JIT ABI were the same as the native C ABI, then there wouldn't even (particularly) be problems with native/VM code linking, or with using globs of assembler... IMO, "bytecoded" need not necessarily mean "terrible native-compiled C interface"... technically, my VMs mostly use the native C ABIs, differing mostly in terms of name mangling (I use a custom name-mangling convention for HLL functions) and simplifying some overly complex edge cases (such as the AMD64 struct-passing rules, ...). my own name-mangling rules and ABI were partly derived from the IA64 C++ ABI (used by GCC), but also somewhat from JNI and the JVM rules. ... or, is it more a worry that delaying some things until JIT-time could hurt the ability to produce as good of optimizations in the machine code?... FWIW, I wrote a C compiler before, just it was much closer to being standard C (rather than the somewhat tweaked version I was imagining). not sure if/when I would get around to the new ideas though... (mostly, I am working more on other things, and using my own custom HLL for a lot of this stuff...). or such...