6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 01, 2024 3:32 am

All times are UTC




Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Thu Jun 02, 2016 6:24 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
whartung wrote:
Also consider runtimes such as the JVM that will switch from interpreted to compiled to recompiled based on runtime behaviors.

Just my opinion, but I don't think Java is a good example. We have been discussing programming languages in which the compiler emits executable machine instructions that will run without the need of a runtime package. Java doesn't qualify in that sense as a compiled language.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 02, 2016 7:37 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
On the subject of writing optimal code, as a human: it's quite amazing the improvements we saw in the 6502 emulator running on the Raspberry Pi as it received expert attention. Although that expert was a human (AFAIK) I think it demonstrated that most programmers stand little chance of writing optimal programs for modern processors.

Second point, have a look at "Stochastic Superoptimization" - it proves fruitful in some cases to let a machine stew over the enormous search space looking for optimal code sequences:
http://blog.regehr.org/archives/923


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 02, 2016 10:51 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BigDumbDinosaur wrote:
whartung wrote:
Also consider runtimes such as the JVM that will switch from interpreted to compiled to recompiled based on runtime behaviors.

Just my opinion, but I don't think Java is a good example. We have been discussing programming languages in which the compiler emits executable machine instructions that will run without the need of a runtime package. Java doesn't qualify in that sense as a compiled language.


Nonsense.

All compiled code have runtimes. Some are as minor as _crt0 and the standard library, statically linked in to the image. Others include more sophisticated capabilities, such as garbage collectors and dynamic module loaders (DLLs, the old DOS overlay managers, etc.), plus all those calls to the local OS. Java's is just a particularly sophisticated runtime. Even Java ME (the Java runtime targeted for embedded applications) includes a JIT layer.

Early Microsoft applications were a combination of native and "p-code". They did this to preserve space.

When the Macintosh switched over from the 68K to the PPC, it ran in a mixed environment, with the 68K code being emulated (and later, dynamically compiled) along side the now-native PPC code. This wasn't just on the application level, but even early system ROMs were a mix of PPC and 68K. The file system primitives were one example that remained in 68K in the early releases. This worked so well, they did the same thing when they moved to the x86. An x86 OS running PPC programs with 68K code in them…makes your head hurt.

The .NET runtime does not compile into "P-Code" like Java does, rather it compiles into an intermediate code that is JIT compiled on load. .NET intermediate code is never "interpreted" like the JVM can do, it always runs native instructions. It's just those native instructions aren't created until the modules are loaded at runtime.

All of these systems were "compiled" in every sense of the word. You can ship Java code with the runtime bundled as a standard EXE file.

LLVM is similar, an intermediate representation that is both statically compiled, and JIT -- yet the host language is simply compiled down in to the LLVM code. Now the compiler writers focus on creating optimal LLVM code while the LLVM creators focus on creating better machine code out of the LLVM intermediate form for the individual CPU sets.

The assertion was that a machine can't create better code than a human. Are there instances where the machine will most certainly be worse than a human? Naturally. But it's no longer a blanket statement that a machine will produce worse code than a human, simply because in many modern scenarios the machine simply has much more information, including dynamic runtime information in some cases, at hand to make better decisions than a human does, particularly in large projects.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 03, 2016 12:51 am 
Offline

Joined: Sun Apr 10, 2011 8:29 am
Posts: 597
Location: Norway/Japan
whartung wrote:
BigDumbDinosaur wrote:
whartung wrote:
Also consider runtimes such as the JVM that will switch from interpreted to compiled to recompiled based on runtime behaviors.

Just my opinion, but I don't think Java is a good example. We have been discussing programming languages in which the compiler emits executable machine instructions that will run without the need of a runtime package. Java doesn't qualify in that sense as a compiled language.


Nonsense.

All compiled code have runtimes. Some are as minor as _crt0 and the standard library, statically linked in to the image. Others include more sophisticated capabilities, such as garbage collectors and dynamic module loaders (DLLs, the old DOS overlay managers, etc.), plus all those calls to the local OS. Java's is just a particularly sophisticated runtime. Even Java ME (the Java runtime targeted for embedded applications) includes a JIT layer.

[..]
In this I'll have to side more with BDD. There's a vast difference between a runtime library in the form of common routines, e.g. libc for C (and you can in principle write C which doesn't need it. And it's not even any different from any library you write yourself, as part of your program), and a VM-based language like Java where you need a bytecode interpreter. It's at that point it makes sense to throw all kinds of JIT and other dynamic methods at it. And yes, that's a job for a computer, not a human. But for bytecode-based languages it would be better to discuss how best to write the bytecode interpreter.. some hand-optimization there, perhaps? (Of course, when you change the original bytecode interpreter to be dynamic as well, then it's back to the computer. The programmer just thinks about the algorithms to apply.)

Anyway, runtime support != runtime library. Not the same thing.


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 04, 2020 7:55 am 
Offline

Joined: Sun Oct 04, 2020 7:49 am
Posts: 1
Hi

Just in case anybody is still interested in this thread, I created a hacked version of JaC64, a java emulator for the Commodore 64, that you can use to run C64 programs while recording the opcodes that are executed by the emulator. From its output, you can run all the analytics you want.

https://github.com/mzattera/JaC64


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 04, 2020 8:57 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
Welcome! Always good to see a tool which helps in analysis: dynamic stats are much more meaningful than stats from a block of code.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 04, 2021 10:10 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
White Flame wrote:
scotws wrote:
As an aside, I'm curious why they used a really big CASE statement for the emulator. I'm throwing together some experiments for a possible 65816 emulator (because there doesn't seem to be a good one for Linux around), and I thought it would be obvious to use a jump table with the opcode value as the index.

Then again, I'm using Forth and he's using C, so maybe that's the difference?


In the article, he describes the reason: The C compiler will put all of the case bodies' variables in the same scope, reusing variable slots and potentially using CPU registers for many of them. I guess that is pretty Forth vs C specific.


In VICE, IIRC, another reason was cache locality (in early machines, remember, VICE is rather old).

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: