From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!goblin1!goblin.stu.neva.ru!newsfeed.pionier.net.pl!pwr.wroc.pl!news.wcss.wroc.pl!not-for-mail From: antispam@math.uni.wroc.pl Newsgroups: comp.lang.ada Subject: Re: Are there any cross-compiler for Embedded Linux on ARMv7? Date: Wed, 7 Apr 2021 19:24:33 +0000 (UTC) Organization: Politechnika Wroclawska Message-ID: References: <298c004a-4d9d-4499-b0af-2eec41c5b516n@googlegroups.com> <87ft03ndyn.fsf@nightsong.com> NNTP-Posting-Host: hera.math.uni.wroc.pl X-Trace: z-news.wcss.wroc.pl 1617823473 12261 156.17.86.1 (7 Apr 2021 19:24:33 GMT) X-Complaints-To: abuse@news.pwr.wroc.pl NNTP-Posting-Date: Wed, 7 Apr 2021 19:24:33 +0000 (UTC) Cancel-Lock: sha1:wy07cgewPV7aEKYH/jQg+7tNaBQ= User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-10-amd64 (x86_64)) Xref: reader02.eternal-september.org comp.lang.ada:61755 List-Id: Paul Rubin wrote: > antispam@math.uni.wroc.pl writes: > > Is there real hardware implementing Java bytecode? > > There have been various hardware assists for Java bytecode, but nowadays > people use JIT compilers. I think it's not reasonable to implement Java > entirely in hardware, since some of the bytecode operations are higher > level, like looking up class methods I guess. I never used Java much > and am glad it is mostly gone ;). To be clear: I am not interested at all in running Java. My interest has following reason: long time experience of several systems indicate that various bytecodes give smallest size of resulting binary. So, having most of binary as bytecode and time-critical parts as conventional code could be valuable optimization: size would be similar to pure bytecode (hance very small) and speed should be close to native code. Now, there is some effort to implement such scheme: fast and seamless switching between bytecode and native code and of course resonably performant execution engine for bytecode. Now, hardware implemented bytecodes should have reasonably good performance and presumably implementation should have fast ways of switching between bytecode and native code. Concerning specifically Java bytecode: I had a short look at it in the past and it looked like resonable bytecode. I admit that I do not remember details. Now, thing like looking up class methods are logically calls to runtime. If this is a bytecode (and not a call), then it is natural for hardware to implement it as vectored control transfer to runtime. And similarly for other "high level" bytecodes. Some time ago I wrote code generator targeting ARM. I could choose mode, for some reasons it would be natural to generate bytecode. So I looked at ARM documentation and all I found basically was "you need support routines, when they are present Java will run". No word about what hardware will do (for example info which bytecodes are implemented by hardware, which trap to software). AFAICS ARM says that sofware-only implementation is valid one, and there is no indication that they provide real hardware support. Of course, lack of info may be due to their silly information policy. But ATM there is no indication that "Jazelle supporting" hardware have hardware implementation of Java (or some other) bytecode. Just extra thing: AFAICS translating on load Java bytecode to a different, but semantically similar bytecode could be a valid implementation. For my purposes such bytecode would be good enough, I do not care if it Java or not. -- Waldek Hebisch