Ĝavo (Java) bajta kodoj kaj retumilo

mi trovis ‘The 7Java® Virtual Machine Specification’. ĉu ĉi tio signifas povas laŭregula fojo kun retumilo? (rapide, eblas vidi paĝoj en kongrueco ). kaj kun 7Raspbian. ĉu Ĝavo (Java) bajtan kodojn komprenas en 4ARM ĉefprocesoro aparataro aŭ necesas programisto skribas rutinoj kun ĉiuj bajta kodoj? ĉu kelkiuj de vij verkas pri ĉi tio? aŭ kaj mi pensas pri akiros plej rapida plato.
-go vegan or something

if you can read or respond ;-) …the java byte codes. they are hardwired in the processor or still must write assembly for them? will it make webbrowsing practical in 7raspbian and here? or should i get a newer faster 4pi or x86(?) board.

you all did not respond. because you not like ™esperanto™? or you worried about legal issues surrounding ™java™?

(my theory was that the ™java™ mode on ™arm™ processor is advantageous because it could escape the processor from the operating system in order to focus on the ™java™ if ™rool™ or ™raspbian™ kernel would let it. i have ™raspberry_pi™ first model so it important to me. i dont think it multicore. so would not even have to argue about stealing byte codes anyway. so i was thinking about putting ™raspbian™ in console or kiosk mode and write something just for web browsing. i need to use internet. i even give my ipad to vegan if needed. i dont want spend my whole life programming web browser not too interesting to me even though it is. my relative said could get me an ™italian™ made ™intel™ card but why i would rather get ™japanese™ ™arm™ with ™norwegian™ video processor, or video recorder player. but it good to learn two sets of assembly language. not that know how to. i assume people who use linux on x86(?) have good browsing experience. but if ™java™ is a legal problem not sure why that would make a difference.)
(so theory b i hope people remember the ™lojban™ court case in which said cannot copyright a language. money is such a stupid thing. btw if have tips or links on what sort of problems exist in a post money world and how resolved that interests me.)
also ™hong_kong™ doesnt have totally it s own or ™costa_rica™ or anywhere ™south_america™ that i know. i try for countries with no death penalty or military.

Java <> JavaScript

I think our friend is referring to the now-deprecated Jazelle mode.

? isnt script slow. .. yes that is correct ™jazelle™ mode. webbrowsers are too slow. except some are very fast but then those ones do not display the pages properly.

I move to ban use of the ™ character forthwith. :)

Jazelle was depreciated and replaced with ThumbEE in ARMv7, so not really relevant any more, unless you have a Raspberry Pi 1B knocking around which has a ARM1176JZF-S processor, the JZ indicating Jazelle.

what you propose to mark words as no translate type? not sure thumb should be translated. i dont think java should be translated as coffee. do you propose ban foreigners. build wall between websites. i overuse theory b.
is there a ’’thumb’’ web browser or virtual machine written yet that runs ™java™?
™thumb™ is 16 bit ™java™ only 8 bit. maybe useful with utf though. i havent totally explored what all ™thumb™ does or why i would need it. but yeah i think should be free open source!! not trademarked.

or maybe can ™thumb™ mode be used in this type of halting manner. no special algorithm just a break to process the ™java™ on the page. and i do mean the ™java™ because that is what is on the web and i thought the explanation for the slow.

but, are there web server portal service that can speed it up? my theory was that was how the newer app on my smartphone actually worked.

‘Raspberry Pi 1B knocking around which has a ARM1176JZF-S’ that exactly what i have. i thought they all still had but just ignoring it because of court case not over probably.

@ Entityfree

Java bytecode gets converted into native code by quite a while now, so there is no need for Jazelle anymore. Thumb instructions are for high code density applications, this has nothing to do with Java bytecode principles. Java bytecode was created for portability and the JIT compiler (from bytecode to native code) has been added later on to improve performance.

Jazelle made sense when Java had no JIT.

If you instead are talking about JavaScript, then JS bytecode is not compatible with Jazelle and btw also JS bytecode these days gets JIT compiled into native code from most of the JS engines. Look at Google V8 for more details.

Hope this helps.

Question: what all this has to do with RISC OS? (given that the question is in community support)

P.S. guys it seems that entityfree talks like a bad AI, so I suspect it may be just a bot…

I have tried to run the first post by ‘entityfree’ through many different translators, looking for what language the post is in, and while it seems to have words from multiple aisian languages, it does not have a grammer that is acceptable to any translator I know of to try.

It is in Esperanto:

I found ‘The 7Java® Virtual Machine Specification’. does this mean can a regular time with a browser? (quickly, it is possible to see pages in compatibility). and with 7Raspbian. does Java (Java) byte codes understand in 4ARM main processor hardware or does a developer need to write routines with all byte codes? do any of you write about this? or and I think about getting a fastest disc.
-go vegan or something

@ DavidS

sure, but this one seems a little too odd:

what you propose to mark words as no translate type? not sure thumb should be translated. i dont think java should be translated as coffee. do you propose ban foreigners. build wall between websites.

;)

it seems that entityfree talks like a bad AI, so I suspect it may be just a bot…

Sadly, entityfree isn’t a bot (I’ve had discussions in the past regarding languages), just somebody who seems to prefer Esperanto and makes very little attempt to communicate in comprehensible English when writing in English. The use of random numbers and punctuation in place of “quotes” being a prime example.

I don’t bother to read this person’s posts any more. I can cope with bad spelling, but stuff that doesn’t flow in a way logical to the language it is written in and littered with trademark symbols? Life’s too short…

For what it’s worth, it seems that the disussion is regarding the ARM Jazelle Java extension. As far as I am aware, this was never publicly documented, and seems to have been more or less been forgotten about as a bit of a non-event.
It was probably the result of some marketing twat thinking “let’s make our processor natively run Java” and all the chip-designing boffins were like “oh crap”. ;-)

i dont think java should be translated as coffee.

See discussion in Aldershot where “the Latin way” (more or less) gets translated into “Costa”. ;-)

I hope to find some information on this so as to share. It could be a good bit of humor to fill plesent of minds within this forum.

There have been many attempts, some recent and some older. I think you may be referring to Lojban (or Loglang)? Either way, that may be a discussion for Aldershot.

We are talking about the Esperanto language that was tryed to be pushed as a universal option?

Yes, that one. Created to be a common language to be used by people A talking to other people B where there was no commonly understood language. In theory people of culture C can join the conversation.

People took one look and, pretty much globally, said Yes! A common language – let’s use English

Given the choice between a language that has been designed (by an andividual or a committee) and a language that has evolved over time, I would take the latter every time. There was a story about Islandic twins who made up their own language in the nursery. Their parents made the mistake of going along with it. When it came to school they were years behind, having missed out on the unquantifiable advantages of learning the vernacular around them, with all its cultural complexities. To design a language (for humans) is to throw the baby out with the bathwater.

Languages are always changing, often at a much faster rate than people realize. There is something both naive and sinister in the idea of a designed language. There have been successful language revivals (Hebrew?), languages preserved artificially (Sanskrit?), and languages invented for fun or fiction (Dothraki et al.), but if they get to be actually spoken they soon shake off their creators.

@ Rick

Sadly, entityfree isn’t a bot (I’ve had discussions in the past regarding languages), just somebody who seems to prefer Esperanto and makes very little attempt to communicate in comprehensible English when writing in English.

In which case my apologies to entityfree and the good news (for me) is I am not the one with the weird-est English in this forum then! :D

I am not the one with the weird-est English in this forum then! :D

Not even close. ;-)

about paolo s comment, i am not sure is just regurgitating(?) , i mean what is the real problem then? it is relevant because i use ™risc_open™ together with my ™raspberry_pi™ so it is the same challenge with ™netsurf™ browser. so, maybe it is compiled into native code but cant that be said of all java virtual machines. but is it really being compiled into native well? who says ™javascript™ is incompatible and why? if ™thumb™ is unrelated why do people talk as if it superceded ™jazelle™ i guess if that is case then well then are people going to write ™thumb™ browser that will convert the ™java™ and be fast? ™raspbian™ has jit (doesnt it?) but it still really slow. on my ™pi™ um, b or model one. but still i proposed i wonder could although it maybe not very secure but could just use the special processor mode for purpose of speed without implementing code. from what you said it sounds like some of bytecodes is hardware is it? but maybe i should read up on what exactly ™javascript™ is. (it seems you disappeared from forum for years strange).
what is google v8?

what is google v8?

A JavaScript engine. JavaScript has nothing to do with Java.

A JavaScript engine. JavaScript has nothing to do with Java

So much easier for people to understand if they call it ECMAscript

@ Entityfree

about paolo s comment, i am not sure is just regurgitating(?) , i mean what is the real problem then? it is relevant because i use ™risc_open™ together with my ™raspberry_pi™ so it is the same challenge with ™netsurf™ browser.

I am sorry mate, I have no idea what the question is here. I’ll try to interpret your message… So you’re saying that you want (somehow) to add support for Java¹ to NetSurf. Now to do that you must add first support for NPAPI API to NetSurf, that’s the API required to run Java Applets. Please note that has stated in multiple comments here, Java Applets are now deprecated by pretty much every web browser on earth with the exception of (lol) Internet Explorer.

Anyway, after you managed to add NPAPI API support to NetSurf, then you need to port a JVM to RISC OS, Jazelle was only part of the equation and it wasn’t a full JVM in hardware.

Then you need to find an ARM CPU that still support Jazelle (seek for old ARM CPUs that have the “J” extension on their name)

And finally you need to make sure to add support for Jazelle to your ported JVM because no JVM supports Jazelle anymore.

so, maybe it is compiled into native code but cant that be said of all java virtual machines. but is it really being compiled into native well?

Yes modern JVMs (Java Virtual Machines) support HotSpot technology which is a JIT (Just In Time) compiler. it compiles Java Bytecode into native machine code. Yes the JIT translation is (nowadays) quite good, Java is used to develop Enterprise Applications that usually require some good degree of performances. Normally the source of performance problems in Java is not the JITed code, it’s the garbage collector and the way it manages memory and memory recycling.

who says ™javascript™ is incompatible and why?

Javascript (probably as Steve pointed out, we should call it ECMAScript to avoid more confusion) is also converted into bytecode, but JS bytecode is NOT the same bytecode as Oracle Java. The term bytecode per-se only means that the instruction encoding is organised in bytes, but such encoded form can differ even from implementation to implementation. Jazelle required Sun/Oracle Bytecode hence it’s not compatible with JS Bytecode.

For example the following JavaScript source:

let test = 1 + obj.x;

Gets converted into something like this on Google V8:

LdaSmi [ 1 ]

Star r0

LdaNameProperty a0, [ 0 ], [ 4 ]

Add r0, [ 6 ]

Now on Google V8 you have the interpreter called Ignition, which is a register machine with an accumulator register. To me it kinda recall a bit the old 8bit CPUs. Please note: all the instructions above that have an “a” like Ld(a) are referring to the accumulator register like it used to be on the 6809 for example.

While the Sun/Oracle Java JVM is a stack based interpreter, here is an example for you:

This Java code:

public static void main(String[] args) {

    int x = 1;

    int y = 2;

    int z = x + y;

}

Gets translated into something like the following Java bytecode:

iconst_1

istore_1

iconst_2

istore_2

iload_1

iload_2

iadd

istore_3

return

Makes sense? (a famous example of stack based programming language is Forth if you want to see more examples of a Stack based VMs)

if ™thumb™ is unrelated why do people talk as if it superceded ™jazelle™ i guess if that is case then well then are people going to write ™thumb™ browser that will convert the ™java™ and be fast?

People say a lot of things, I do not generally listen or read “approximate” comments on the internet, but anyway let’s answer this one too.

Jazelle was an extra “decoder” added to the ARM core to interpret Java byte code (basically, IIRC, the Jazelle decoder was placed between the instruction cache and the ARM pipeline, so that it could decode a Java bytecode into ARM machine code). Because of that Jazelle was not decoding every single Java bytecode (IIRC) only the bytecode that could be supported in such a process. When the bytecode was decoded into ARM instruction such instruction would be executed by the ARM pipeline as ARM native code.

Jazelle decoder was capable of decoding instructions encoded like this:

opcode (8 bit), operand 1 (optional), operand 2 (optional)

Now THUMB is a totally different beast, thumb code direct maps on ARM32 code (and THUMB32 to ARM64). Thumb is aligned 16bit and maintain an ARM like encoding.

So thumb encoding is like:

Opcode (6 bit), operands (10 bits)

So, as you can see, they are different. However Thumb was introduced to have high density code compared to the ARM32 instruction set.

And finally Jazelle actually had two different implementations: Jazelle DBX (which is the Java bytecode decoder) and Jazelle RTC (RunTime compilation) which was capable of supporting different bytecode languages and it was more complex than DBX.

So, if you were referring to Jazelle RTC, this is the Jazelle that is close to Thumb-2 and that offered basically a modification of thumb-2 to achieve the goal. The modification was the addition of 12 new instructions to the 16bit Thumb that allowed thumb to be particularly suitable for JIT compilers (note JIT compilers) used by Python, Perl, .NET and Java to that point. So, I guess the interpretation of this from the “Internet” was that Thumb superseded Jazelle, but as you can see the two are different and ARM released such technology under the name of THUMB-2EE (in this forum there are ex ARM employees which may know this naming way better than I do).

Now Thumb-2EE could be used for both Java and JavaScript bytecode, BUT the reading line here is of the JIT compiler, not the pure bytecode, which (again) is different and so, I think there is a bit of confusion (probably Rick and others can help me understand the questions better).

™raspbian™ has jit (doesnt it?) but it still really slow.

Ok, so Rasbian is an Operating System (it’s basically Debian ARM with some prebuilt package specific for the RPi and some GUI item), so saying that “Raspian has JIT” (with all the respects) means nothing. You’re probably talking of Google Chrome browser that has JIT for Javascript (again Chrome and Firefox etc… no longer support Java Applets).

Linux is generally slow on ARM because Linux has a set of assumptions (mostly coming from the Intel world) which don’t suite ARM really well and, on top of that, Linux presents a lot of abstraction layers which obviously make it slower on a per core base than, for example, RISC OS… However, Linux is way faster than RISC OS for parallel execution and that is because RISC OS has no concept (at the moment) of multiple cores. In other words, a full call stack on Linux from UI to Kernel executed on a single core, is always slower than on RISC OS, while parallel load on Linux is way faster than on RISC OS.

Emulation and interpretation are typical examples of single core processing, so on these, Linux may appear slower than RISC OS, but as soon as you try to exploit the parallelism of ARM then you’ll immediately see how much faster Linux can become right now (please note performance improvements in parallelism are variable and subject to Lamdal law!).

on my ™pi™ um, b or model one. but still i proposed i wonder could although it maybe not very secure but could just use the special processor mode for purpose of speed without implementing code.

So, if you are talking of executing everything in EL2 (privileged mode), sure you would not have the overhead of Processor context change, but these days such overhead is minimal compared to the 90s. What does help a lot on rendering web pages is exploiting parallelism and using hardware acceleration in the GPU for example, RISC OS doesn’t support either at the moment.

from what you said it sounds like some of bytecodes is hardware is it?

Yes Jazelle DBX did decode bytecode in hardware (however bytecode per se it’s a form of ISA optimised for software interpreters), while Jazelle RTC or Thumb-2EE did NOT, they provided support to improve performance of JIT compiled code which in order allowed “hardware acceleration” of .net, python jitted bytecode, perl and java jitted code.

but maybe i should read up on what exactly ™javascript™ is. (it seems you disappeared from forum for years strange).

Yes, I strongly recommend to read more about JavaScript and Java to understand well how they works.

Yes, I have “disappeared” from this forum and other RISC OS forums for many years, because RISC OS was (back then) still copyright (IMHO useless for an OS) and there were companies fighting (useless for the OS and for the community), quite a few in the community were being aggressive (even more useless and completely pointless), so it was not the place for me anymore. I have focused on my career and other platforms that were more fun and communities that were more joyful and less grumpy ;)

ROOL’s guys (made the miracle) and managed to change the RISC OS distribution license, the community here became more welcoming (or the punks simply left because it was clear they weren’t doing anything useful anyway), so things got interesting again for me, hopefully things will stay so for long time :)

what is google v8?

https://www.youtube.com/watch?v=PsDqH_RKvyc

Enjoy the video! :)

Everyone else, apologies for the long response! As I said before, brevity is not my virtue and I do have some troubles understanding entityfree, so hope my responses were good/useful.

¹ because you’re insisting on Jazelle, hence you must be talking about Java.

Java Applets are now deprecated by pretty much every web browser on earth with the exception of (lol) Internet Explorer.

IE has the distinction of being deprecated itself.
Not that you don’t, still, find examples of people producing browser based content that only works as designed on IE – yes, insane.