Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eternal Hope Newsgroups: comp.lang.java.programmer Subject: Re: question: in order to use java on/in a graphics card Date: Sun, 23 Aug 2015 21:26:59 +0100 Organization: A noiseless patient Spider Lines: 44 Message-ID: References: <6012dfa0-59b3-4b84-8d79-e6ccbc7f6030@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 23 Aug 2015 20:25:05 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2ab430ef8c6b5deb5816c858366218e1"; logging-data="18340"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/axe2sR1h2hi5yJbeMIQcMKclapZZtO18=" User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <6012dfa0-59b3-4b84-8d79-e6ccbc7f6030@googlegroups.com> Cancel-Lock: sha1:RAym6oRNPniHNJ6GXTmrwuu/UyU= Xref: csiph.com comp.lang.java.programmer:32423 On 23/08/2015 16:18, gdotone@gmail.com wrote: > question: in order to use java on/in a graphics card, where java is directly producing the action of the card, the card must have a JVM to produce byte code the the graphics processor can deal with? > Interesting question Imagine a grossly oversimplified computer with 3 layer architecture, there is software at each layer. We also ignore VM optimisations like JIT compilation etc. Top layer is the application layer, this is where the programs you use day to day exist. Middle layer is the driver layer, a driver is the (bi directional) software interface between the application layer and the hardware device. (we are ignoring the operating system but who needs one of those anyway :-)) The hardware layer contains software that drives the device, usually stored in some kind of ROM, sometimes a PLA sometimes flashable etc Java is an interpreted language, bytecode is directly executed by a virtual machine, when a VM sees a bytecode instruction, it 'looks up' the relevant machine instruction for the underlying platform it is currrently running on and this is what gets executed by the hardware. Java bytecode is not directly executed by the hardware on the hardware device So, presumably you want to write the ROM resident code in Java. I can't see how this would work as sooner or later something is going to have to translate the bytecode into directly executable code and this something would have to produce the 'binary' bytes that is directly executable by the hardware. Java doesn't do this so you would 'probably' use C or assembler to produce the 1s and 0s (if you like) that will cause the device to actually do it's thing. So, no, I don't think it's possible to expunge all traces of C and/or assembler, or rather the executable output thereof from the device. As always, I await correction and chastisement -- Laughing Spam Fritter