Spectre / Meltdown

What are you talking about?

Javascript != Java and has never been even remotely connected with Java except that Netscape tried without success to build it into their browser. Meanwhile they had a parallel project for an interpreted language called Scheme which added a few syntactical and functional elements copied from Java and ended up being called LiveScript, then renamed to JavaScript and later standardised as ECMAScript.

So, the differences are:

- the two languages are syntactically different apart from some features in common with other languages such as curly brackets and other syntax that originated from C.

- Javascript is interpreted while Java is compiled

-Javascript is a weakly typed while Java is extremely strongly typed, which allows the compiler to spot and report a lot of carelkess nonsense code that isn't found until code in a lot of other languages (C to name but one along with most interpreted languages such as Perl and Python) are test run. And if the programmer is careless and skimps testing, so missing these mistakes, they will can and do live production runs to crash.

Livescriot - see above.

Python is compiled, though the compiler is semi-hidden as an interptreter. Its actually extremely portable - it will run anywhere that has a port of the interpreter. One of its main failings is that it has poor backward compatibility: A Python 2.7 program probably won't run on a Python 3 interpreter.

This is unlike Java: I have code written back when Java 1.4 (AKA Java 4) was the thing thats currently running in an Open Java 1.8 (aka Java 8) JVM using the Java 8 standard class library and that was last compiled with javac 1.4

Not true. Java programs using the SWING GUI run just fine on my Linux systems and would run equally well under Windows - no recompilation needed.

But most Java applications run on server farms. Where adequate documentation exists large, complex COBOL systems have been or are being reimplemented in Java.

There is JavaScript which has been on browsers for a long time (and has seen increasing use and increasing support) and there are Java applets, which are a completely different beast.

Applets are downloaded by a page and run on the browser. They have had all kinds of problems, I haven't seen one for years because much of the functionality (but perhaps not all) they were intended to provide, e.g., runtime graphics, has been addressed better by JavaScript and HTML5.

Interpreted and compiled implementations are different points on a continuum, they are not one-or-the-other propositions.

There are certainly things called JavaScript compilers running on browsers these days (I believe the one used most widely is from Google and was a large step forward compared to previous, interpreted implementations in terms of performance of the code produced). I don't know to what degree it "compiles" JavaScript, I doubt it goes to native code.

Java has been implemented in more than one way. Including in the "compiler" from Oracle, nee Sun, which, I am told by people who have worked on it, contains three separate Java compilers in the same javac binary. Which compiler you get is determined by which flags (among 120 or so) you choose on the command line and this internal structure is not visible to the user. None of these, to my knowledge, "compile" to native code, they compile to an intermediate language which is then interpreted.

Unclear how you intend that to square with your claim that Java (vs. JavaScript) is compiled.

Tom

Java is complied into Java Bytecode which is essentially machine code for an idealised virtual machine (sort of like Pascal P-Code or BCPL INTCODE). The bytecode runs in a Java Virtual Machine (JVM) which either interprets, compiles or JIT compiles (most common I think) the bytecode.

The first time I saw what is now known as JIT was in the Newbrain BASIC which compiled a line at a time and kept a cache of compiled lines in spare memory. The technique worked wonders for benchmark scores.

Indeed, and Java applets dies almost as soon as they appeared because the download mechanism was fairly flaky. Applets were compiled using the standard Java compilers. They had nothing to do with Javascript.

I'd disagree here. Yes, interpreted languages often use some sort of compilation stage as part of loading the script (awk, Javascript, most BASICs and some (Python) even allow you to capture and reuse the compiled script, but 'compilation' as commonly used, means that compilation is a separate process from executing the program (C, C++ Java, COBOL.PL/1...) and, for some languages there may linkage process (C, C++, COBOL, PL/1) and even more complex as well (C++ and some COBOL compilers translate the source into C and then compile that.

Most 'run the source' systems generate P-code and run that with a P-code interpreter.

Java does that: javac reads Java source and generates P-code to a .class file and that is executed by the JVM, 'java'. I think, but can't prove, that the term P-code dates from the UCSD Pascal system, which was one of the first to us a compiler to generate an easily interpreted binary format, called P-code, which was executed by a runtime process. UCSD Pascal was around when the 8080, Z80 and 8086 chips were cutting edge microprocessors.

Quite so - and ad a result the same compiled .class file can be run unchanged on any hardware and OS which has a port of the JVM installed.

Quite simple. javac, the Java compiler outputs a .class file. When you want to run the compiled code, you run 'java', the JVM, which also loads any standard class files from the standard library that the application needs and then runs the result.

If the program has a graphical interface the JVM loads the AWT and SWING classes that implement the GUI interface, along with keyboard and mouse handlers. It goes without saying that the lower level AWT and SWING classes used by a Linux JVM are not the same as those by a Windows JVM, but the top-level classes (JPanel, JWindow, JMenu, JFileChooser, JButton etc that the programmer uses to define what his application looks like) will be the same for all hardware and operating systems.

But don't just speculate: install both Java and Javascript packages on your RPi and start writing code. You'll soon see the differences.

Dana 2 Sep 2020 00:50:44 GMT, Charlie Gibbs napis'o: [snip]

I do not understand why nobody writes what it is: M$ took Java, modified it, stole the whole idea... and called it .Net. Is it so hard to write that?

"Nikolaj Lazic" wrote

| I do not understand why nobody writes what it is: | M$ took Java, modified it, stole the whole idea... and called it .Net. | Is it so hard to write that?

It's not true. MS created their own Java variant, thinking they were doing a better job. They were sued. They lost. So they removed it. Later they built .Net, which was intended as a web services system. (I provided that link a couple of days ago.)

The two things were very different. The purpose of such a product was up in the air, since Java failed to find a place in webpages or on desktops. The commonality was the idea of building a giant, bloated, superfluous layer between the platform API and programmers, for ease of use, RAD development, and to keep programmers out of the actual platform API. Do you think Sun should have had a license in perpetuity to get fees for the idea of bloated wrappers?

It's true that .Net then competed with Java server-side. Why not? It was a wrapper system for use on their own OS!

I thought the Google/Oracle lawsuit was interesting. I haven't really followed it, but as I understand it, Google copied the object model function names while creating their own code behind it. So presumably Java code could be easily switched over. Should the Java copyright cover function names? If I write a function called OpenFile, can I copyright that? It's a tricky issue. On the one hand, it's absurd to claim they own the names. On the other hand, without owning the object model their system is vulnerable to competitors. It's a bit like aftermarket auto parts. Should Ford have the right to stop maunfacture of any part designed to work in a Ford car? Fortunately they don't have that right. I don't see why Oracle should, either. If their system isn't superior then they deserve to fall to Google or generic copiers.

"Martin Gregorie" wrote

| On Tue, 01 Sep 2020 21:07:14 -0400, Mayayana wrote: | | > Yes. Except that it didn't really work. And it never belonged | > in webpages. And it never belonged on the desktop. As I said, | > it's used for in-house applets, just as .Net is. Neither of them is well | > suited to desktop. What is? Compiled software. | > | What are you talking about? | | Javascript != Java

No. And I have no idea how you got off on javascript. You can call Java compiled if you want to count JIT, but you know perfectly well what I'm talking about. Java, like .Net, is far slower than native compiled software. Even if it were native compiled, it still inserts a superfluous layer. Neither has any place on the desktop.

| Python is compiled, though the compiler is semi-hidden as an interptreter. | Its actually extremely portable - it will run anywhere that has a port of | the interpreter. One of its main failings is that it has poor backward | compatibility: A Python 2.7 program probably won't run on a Python 3 | interpreter. |

That's fine, but it's not really cross-platform. These are all extra wrappers. You write a program that's not cross-platform and that calls some kind of framework or runtime that's customized for each platform.

| > Great, but not for desktops. | > | Not true. Java programs using the SWING GUI run just fine on my Linux | systems and would run equally well under Windows - no recompilation | needed. |

Then why is there virtually no Java software on the Desktop? Even .Net is not common. It's more common now, since MS started pre-installing the runtimes. But like Java, it's not optimized for desktop.

| But most Java applications run on server farms.

Isn't that what I said in the first place? So why so much argument? I've got nothing against Java... so long as you keep it off my desktop. :)

I don't thing yo go.

Its compiled, with a separate compiler, javac, that generates bytecode in .class files. These are loaded into the JVM -NOT the source!.

The JIT is part of the JVM along with the garbage collector which keeps off-stack memory tidy., but its best regarded as an optimiser because its purpose is to compile frequently used parts of the bytecode into native binary whole your application is running.

Might have been once, but current versions are pretty slick. Its a bit slower when its getting started and pulling in library classes from disk, but that its not what you'd call slow.

Pass, though its not an rare as you seem to imagine. Quite a lot of IDEs are written in Java, notably IntelliJ IDEA and Eclipse.

Mono?s CIL JIT was empirically beating GCC on computationally intensive code a decade ago (probably by making better register allocation choices although I didn?t delve into it deeply). No idea what the situation is today but I?d expect them to be pretty similar.

Yeah, maybe optimal reordering of instructions and branch prediction too, in combination with register allocation. C# was brilliant at numerical analysis type performance right from the get-go.

I have a vague memory of .net runtime statistics being stored and used to optimise subsequent runs of a program, but after a quick google I'm not sure if I just made that up.

I should try .Net core on Raspbian.

No mention of pipelines in my copy of "Assembly Language Programming for the BBC Microcomputer" by Ian Birnbaum. I threw most of my old books away, but this is a book I truly loved, right up there with K&R.

Most of my knowledge of pipelines comes from circa 1990 and the MIPS based Digital computers, I guess these cpus were contemporary with the ARM development.

I think that would be Managed MPGO in the language used by

Nor in this seminal machinecode book of the 80's

Neither the 6502 or Z80 were pipelined, but if they were it wouldn't be something that needs to concern the programmer, even when using assembler. The same is true for the ARM.

This isn't the case for all processors, as some early RISC chips such as MIPS expose the effects of pipe-lining by having a branch delay slot i.e. the instruction after a branch will be executed regardless of whether the branch is taken or not, as it is already in the pipeline.

Most other processor flush any instructions in the pipeline after a taken branch, which was could be wasteful until good branch prediction came along, although most slots were filled with No Ops in practice. Processors also have much longer pipelines now, and it would be very difficult to code for a variable number of branch delay slots.

ARM tackled pipe-lining issues in in Aarch32 by eliminating the need for most small branches by using conditional instructions, which was great when programming by hand. This has been deprecated by better branch prediction and the use of Thumb, which has an IF THEN ELSE instruction to determine which of the following 4 instructions is executed depending on a condition.

Aarch64 has eliminated conditional codes from all instructions except for branches, but has a small number of conditional arithmetic instructions. For example CSEL allows you to calculate the result of both the THEN ELSE instructions (usually in parallel with superscalar chips) then chose which value to use.

---druck

sk,

ntensive

tion is

I'd say that from what I'm doing the Mono CIL on AMD64 is between 1.5x and 8x slower. For computational intensive stuff probably about 4x. Half

that on the Windows CLR.

On the Raspberry Pi 4B mono is about 9x slower for both 32 and 64 bit OS's, so a far less mature JIT.

Its not quite as bad on Python JIT. pypy comes 10x slower than gcc on AMD64, but 13x slower on 32 bit ARM. Don't even try pypy on 64 bit ARM as there's no JIT and its hundreds of times slower, 3x worse than interpreted Python, slower even than Perl!

---druck

In the 32 bit ARM (ARM7TDMI and relatives), the conditionality is in the top 4 bits of most instructions.

In the same chips, the pipelining peeks in two places: - offsets of PC-relative addresses, - return addresses of exceptions.

Most of the NV (never) variants have been repurposed as new instructions

now, as they were never that useful.

Well remembered. It was a side effect of the very simple logic in ARM2 which had a 3 stage pipeline so value of the PC register was always +8* of the currently executing instruction (ignoring Thumb which is +4).

Its a shame there wasn't the budget for a few extra transistors to 'fix'

this at the time, because this behaviour has had to be preserved on every subsequent ARM, no matter how many stages it has.

• There is one place where it is +12, can't remember where though!

---druck

It is differernt in the different traps (code-generated exceptions), depending on how far the instrucction handling has proceeded before the trap was sprung.

If memory serves correctly one reason for the conditional instructions was that it made it possible to do a pipelined 32 bit processor with a very low transistor count more like that of a 16 bit processor.