flat assembler
Message board for the users of flat assembler.

Index > Heap > JVM assembler?

Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
I was just reading a Wikipedia article about Java bytecode, with some interesting fragments like:
Wikipedia wrote:
Java programmer does not need to be aware of or understand Java bytecode at all. However, as suggested in the IBM developerWorks journal, "Understanding bytecode and what bytecode is likely to be generated by a Java compiler helps the Java programmer in the same way that knowledge of assembler helps the C or C++ programmer."

It is possible to write Java bytecode in hand, however this method is never used in real life because nowadays the compilers are able to compile well performing code and no person is able to comprehend a piece of Java bytecode of considerable size.

I just started to wonder: is the last statement really true? Or if someone Wink wrote a decent assembler for the java bytecode, would it become possible to develop it just like we all do it with x86 assembly?
Post 03 Jul 2006, 11:00
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
Sure, but who says Java byte code is as easy to write in as x86?
.NET has its own byte-code, an assembler for it, but the architecture reminds of a stack processor - not really nice to program at all.
And afaik, there were efforts before to do .java -> native .exe compilation, but that destroys the whole point of Java and portability.

And forget Java too, .NET is the future Smile
Post 03 Jul 2006, 11:03
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
I see more and more hardware supporting the JVM "natively", is the same happening with .NET?

As for the stack processor - the x87 is also stack-based, which doesn't mean it's so hard to programm it (even if harder that standard x86 code). Maybe some macros would be of help? Wink
The main point where writing such code directly appears to me nicer that writing HLL code is branching - and there are, of course, branching instructions (well, tons of them) in Java bytecode. Though, perhaps, they may be not as handy as flag-based branches on x86...
Post 03 Jul 2006, 11:20
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Have you tried the JDK? I tried it one year ago or so and I'm pretty sure that it comes with a disassembler, possibly it comes with an assembler too and I didn't pay attention...
Post 03 Jul 2006, 15:02
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Post 03 Jul 2006, 16:27
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Quote:
It is possible to write Java bytecode in hand, however this method is never used in real life because nowadays the compilers are able to compile well performing code and no person is able to comprehend a piece of Java bytecode of considerable size.

You know how funny are these kind of statements to me? Wink

You know why? Because it's completely childish from my point of view. When you design C, C++, or Java code, why does it matter HOW you design it? Why, because I thought compilers can get the BEST result. It doesn't matter if I design it to waste 5KB of memory --> the compiler will surely choose the BEST method EVER. He knows about Z-buffering, he knows about what I want to accomplish. So he chooses the best algorithm ever possible. But, to be honest, we humans "learn" such algorithms and "think". How was the compiler "born" with such skills and knowledge? Unless someone programs it like it, it doesn't know. But oops, the programmer of it is still a human, not a god. Laughing it's so foolish and common that I am trying to live with it as other "foolish" and "manipulating" statements in the press or mass-media Wink

In my opinion it is always the DESIGN of you code that makes it optimized. And also, in assembly you design it differently since you are aware of everything. In HLLs, you let the compiler design the low-level stuff, and you the high-level stuff. But the more high-level a language is, the less optimized the output will be. Why? Because it's based on information. In assembly, the information is extremely exact -> you give the compiler everything at all, so it will produce the same output. In HLLs, you give less, more abstract information to the compiler, so he has to guess some things which probably were designed differently if you had the time to do it yourself.

The simplest way possible to TRULY show that such statements are invalid: "Disassemble the HLL output and improve at least something there". I don't mean this is a good idea, since you STILL use the HLL design which is usually much more unoptimized than a Low-level design, but the point is that you can always show that such statements are false. Wink
Post 03 Jul 2006, 19:07
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
...and I love Wiki because of the ideas it gives me (and as I see to Tomasz aswell) and the way it sucks you in. Link to a link to a link to a link....before I got back to this FASM board again.

Wiki is "evil" - it holds too much useful info. If you start reading it - you can't put it away - just like a good book.
Post 04 Jul 2006, 18:19
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
0x4e71



Joined: 25 Feb 2004
Posts: 50
0x4e71
well it's easy to take a peek
Code:
public class ha {
        public static final void main(String args[]) {
                System.out.println("You damn world!!");
        }
}       

javac ha.java
javap -c ha 

Compiled from "ha.java"
public class ha extends java.lang.Object{
public ha();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>"Sad)V
   4:   return

public static final void main(java.lang.String[]);
  Code:
   0:   getstatic       #2; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:   ldc     #3; //String You damn world!!
   5:   invokevirtual   #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   8:   return
}

    


In general, I think:

  • For us, assembly coders, java byte code is still pretty much high-level, it's a lot more like the intermediate code representation used by multi-pass compilers.
  • There is not much interesting stuff to do in term of optimization when looking at byte code, as the REAL optimization work (somehow in contraddiction to what the article says) is done by the JIT and not by the HLL->bytecode. So, a pretty much brain dead code generator will still generate good enough byte code.
  • In terms of reverse engineering of large programs, UML is a whole lot more useful than looking at java byte code.
  • It is STILL useful to know byte code, that is how non-Java JVM languages are implemented and also why there is work going on adding some byte code extensions to make implementation of dynamic languages easier.


My lim 1+x x->1 cents

/L

P.S. not sure how the unhappy face came out, LOL Surprised
Post 04 Jul 2006, 20:32
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
ARM have the Jazelle extension. It is an extra mode of execution that directly executes most of the java byte codes without using an interpreter. Although, some byte codes are too complex and generate exceptions so that the supervisor software can emulate the code.
Quote:
Because it's based on information. In assembly, the information is extremely exact -> you give the compiler everything at all, so it will produce the same output. In HLLs, you give less, more abstract information to the compiler, so he has to guess some things which probably were designed differently if you had the time to do it yourself.
That statement is right on the mark and I agree completely.

There is still a lot of "flag waving" about how great HLL compilers are at generating optimised code. This is mostly started by the makers of the compilers who think that their particular code is so wonderful that it "just must be better than any assembly coder". Of such statements are not true, because of how the information is presented to the compiler in various languages.

I would bet that given a byte code assembler an experienced programmer could make much better optimised code than any compiler for a non-trivial task. However the gain will always be limited by the actual interpreter that is used to run the byte codes.

.NET is not the future. Is it just a marketing ploy by Microsoft to gain more market share. There is no advantage to using .NET over any other similar system (Java). Don't be misled by the very good (and expensive) marketing from Microsoft. Say what you like about Microsoft but you have to admit that the marketing team is top notch.
Post 04 Jul 2006, 23:28
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
revolution, there is a little advantage, you can use a variety of languages with .Net while with Java well, you can just use Java language...

About .Net is not the future I hope that you are right, actually I hate VMs Very Happy (except in enviroments like web and mobile phones).
Post 05 Jul 2006, 00:00
View user's profile Send private message Reply with quote
0x4e71



Joined: 25 Feb 2004
Posts: 50
0x4e71
locodelassembly wrote:
revolution, there is a little advantage, you can use a variety of languages with .Net while with Java well, you can just use Java language...

Wrong, wrong, wrong, absolutely brimming over with "wrongability"!

Take a look at:
http://www.robert-tolksdorf.de/vmlanguages.html
also note that many generate Java bytecode. There is a bunch of "assemblers" in there too.

locodelassembly wrote:

About .Net is not the future I hope that you are right, actually I hate VMs Very Happy (except in enviroments like web and mobile phones).

indeed.. (plus a bunch of server side stuff..) fully agree.
Post 05 Jul 2006, 16:08
View user's profile Send private message Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
.NET can never replace C/ASM, but i learned C# and it is very nice
Post 08 Jul 2006, 01:37
View user's profile Send private message AIM Address MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
revolution wrote:
There is still a lot of "flag waving" about how great HLL compilers are at generating optimised code. This is mostly started by the makers of the compilers who think that their particular code is so wonderful that it "just must be better than any assembly coder". Of such statements are not true, because of how the information is presented to the compiler in various languages.
Very Happy

This is because the information is STILL written by humans. Think about it Wink If the compilers were not based on human information, why would we need programmers at all? Also remember that we, humans, "learned" all the tricks/algorithms/whatever else, and because of that we can program stuff better, because we think. Compilers just see the information we give to them and, depending on their implementation, might give more or less optimized code. There ARE chances that the compiler will optimize that code 100% (though such chances are rare), but it will always optimize THE CODE YOU GIVE HIM (i.e it will not create other algorithms). So they will only optimize the information you are giving to him (aka code) and will NOT optimize the design. To perform efficient design, you need a solid knowledge of the internals (aka asm). Wink

Even if you think you optimized something in asm 100%, there is surely another way to do it with a different design (perhaps even a total redesign). So even though you optimized that code, other algorithms can still be used, and such algorithms are only designed by humans, not compilers. What I am saying is that in assembly, being low-level, the design is much more efficient than a high-level language's design, and the compiler who doesn't know anything about the code and what it's supposed to do (don't make me wrong, assemblers are compilers too, they do not make magic, but in assembly it's the effort of the human, not the assembler/compiler). The assembler just translates YOUR precise information and design in machine code. Very Happy

That being said, if you have a lot of imagination, writing in machine code can be even more efficient, though there are some limits as to how far we can go. Just remember the fact that there are always better methods to do something. Wink

_________________
Previously known as The_Grey_Beast
Post 14 Jul 2006, 12:48
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Post 16 Jul 2006, 05:02
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
The_Grey_Beast wrote:
Quote:
It is possible to write Java bytecode in hand, however this method is never used in real life because nowadays the compilers are able to compile well performing code and no person is able to comprehend a piece of Java bytecode of considerable size.

You know how funny are these kind of statements to me? Wink

You know why? Because it's completely childish from my point of view. When you design C, C++, or Java code, why does it matter HOW you design it? Why, because I thought compilers can get the BEST result. It doesn't matter if I design it to waste 5KB of memory --> the compiler will surely choose the BEST method EVER. He knows about Z-buffering, he knows about what I want to accomplish. So he chooses the best algorithm ever possible. But, to be honest, we humans "learn" such algorithms and "think". How was the compiler "born" with such skills and knowledge? Unless someone programs it like it, it doesn't know. But oops, the programmer of it is still a human, not a god. Laughing it's so foolish and common that I am trying to live with it as other "foolish" and "manipulating" statements in the press or mass-media Wink

In my opinion it is always the DESIGN of you code that makes it optimized. And also, in assembly you design it differently since you are aware of everything. In HLLs, you let the compiler design the low-level stuff, and you the high-level stuff. But the more high-level a language is, the less optimized the output will be. Why? Because it's based on information. In assembly, the information is extremely exact -> you give the compiler everything at all, so it will produce the same output. In HLLs, you give less, more abstract information to the compiler, so he has to guess some things which probably were designed differently if you had the time to do it yourself.

The simplest way possible to TRULY show that such statements are invalid: "Disassemble the HLL output and improve at least something there". I don't mean this is a good idea, since you STILL use the HLL design which is usually much more unoptimized than a Low-level design, but the point is that you can always show that such statements are false. Wink


Agreed... I never liked what compilers did to my programs.. thus why i wanted to learn assembly... There's alot of developer junk in there... They say then to make "release compiles" but you do that and ti's still not good. It's funny... actually... "you should only use assembly where speed is required." I can think of a few examples... Halo 1 pc... Call of Duty... hm... Yet those projects are big.... And here's what they say about that "for big projects, use C/C++ because assembly is way too much code." They're essentually saying, "Never use assembly." You ask them that and then they say there is use for it... But only when faster calculations are needed... which common sence says only in big projects, where assembly is supposedly too much code and would take years to write. I hate how people bash assembly.

Quote:
...and I love Wiki because of the ideas it gives me (and as I see to Tomasz aswell) and the way it sucks you in. Link to a link to a link to a link....before I got back to this FASM board again.

Wiki is "evil" - it holds too much useful info. If you start reading it - you can't put it away - just like a good book.


Wiki gave me 2 good links in less than 5 minutes, while it took me hours and hours with google and yahoo to find all bad links and not good ones... The 2 good links i found were a tutorial on assembly, and flat assembler's website...

As for my opinion on java... The ones who code it think it's the best code in the world and stuff... makes me wonder if it was coded in VB or something. lol And that reminds me, the wacko of a programming teacher at my school has already said that VB is just as good as C++.
Post 24 Jul 2006, 21:01
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
kohlrak wrote:

actually... "you should only use assembly where speed is required." I can think of a few examples... Halo 1 pc... Call of Duty... hm... Yet those projects are big.... And here's what they say about that "for big projects, use C/C++ because assembly is way too much code." They're essentually saying, "Never use assembly." You ask them that and then they say there is use for it... But only when faster calculations are needed... which common sence says only in big projects, where assembly is supposedly too much code and would take years to write. I hate how people bash assembly.


The idea is not to write the entire project in assembly, but to optimize the speed-critical parts. The 20/80 or 10/90 rule comes into mind - the "10% of the code that runs 90% of the time" is what you need to optimize, the rest is a waste of time. And optimize doesn't, by the way, necessarily mean to use assembly - often some different data structures or a better algorithm is enough. When asm really matters is usually in audio/video/compression and the likes.

By the way, Halo 1 isn't all the CPU intensive - remember that it was originally developed for a 500MHz Pentium3 AKA the xbox. When it was released for PC, it had "relatively high" demands for your video card though... assembly couldn't really help there.
Post 25 Jul 2006, 11:18
View user's profile Send private message Visit poster's website Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
f0dder wrote:
By the way, Halo 1 isn't all the CPU intensive - remember that it was originally developed for a 500MHz Pentium3 AKA the xbox.


I believe it's 700mhz

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 25 Jul 2006, 12:50
View user's profile Send private message MSN Messenger Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
f0dder wrote:
kohlrak wrote:

actually... "you should only use assembly where speed is required." I can think of a few examples... Halo 1 pc... Call of Duty... hm... Yet those projects are big.... And here's what they say about that "for big projects, use C/C++ because assembly is way too much code." They're essentually saying, "Never use assembly." You ask them that and then they say there is use for it... But only when faster calculations are needed... which common sence says only in big projects, where assembly is supposedly too much code and would take years to write. I hate how people bash assembly.


The idea is not to write the entire project in assembly, but to optimize the speed-critical parts. The 20/80 or 10/90 rule comes into mind - the "10% of the code that runs 90% of the time" is what you need to optimize, the rest is a waste of time. And optimize doesn't, by the way, necessarily mean to use assembly - often some different data structures or a better algorithm is enough. When asm really matters is usually in audio/video/compression and the likes.

By the way, Halo 1 isn't all the CPU intensive - remember that it was originally developed for a 500MHz Pentium3 AKA the xbox. When it was released for PC, it had "relatively high" demands for your video card though... assembly couldn't really help there.


and i thought all that calculating was the models... Aren't they done locally then sent to the vid card?
Post 25 Jul 2006, 18:19
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
okasvi wrote:

f0dder wrote:

By the way, Halo 1 isn't all the CPU intensive - remember that it was originally developed for a 500MHz Pentium3 AKA the xbox.

I believe it's 700mhz

My bad, it's 733MHz (128kb cache?) with 64MB ram, and nVidia GPU that's somewhere inbetween GF3 and GF4. Not very powerful by today's standards.

kohlrak wrote:

and i thought all that calculating was the models... Aren't they done locally then sent to the vid card?

I haven't looked into how much work Halo does on the GPU (ie, does it manually animate models or does it use vertex shaders), but it does a fair amount of pixel shader work...

Also, remember that an XBOX doesn't run very high resolution, since the primary output is TV. If you want to compare PC version to XBOX, you should probably run a low resolution like 800x600 or edven 640x480. From a quick google, it seems that NTSC has 525 scanlines and PAL has 625 - so 800x600 is probably a relatively fair comparison.
Post 26 Jul 2006, 08:36
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
And optimize doesn't, by the way, necessarily mean to use assembly - often some different data structures or a better algorithm is enough.
That's the primary point of my reply -- the design (or algorithms). But also note that in assembly you think "differently", i.e not abstract, etc.. if you are abstracted and think that a multiply is 10 times faster than an addition, then you would probably design it extremely bad. Note this was a very bad example, but the idea is there.

What I hate about OOP is that it completely limits your thinking to abstracted things. I can't even begin to list all the codes I saw which has overbloated junk in classes, etc. -- and that's because OOP restricts your "human" thinking. A lot of guys and gals are so abstracted that they lose the point of computers and think they are even writing books instead of code (i know I overexaggerated), but some just feel that if they EVER overload an operator once, they need to do it EVERYWHERE else, thus increased bloat. Far too much have I seen OOP code that has a lot of functions that are either empty or completely bloated (i.e not necessary for this purpose). I hope I explained it well this time.

Yes I agree it's the choice of algorithm design that is most important, but HLLs just limit your thinking into abstract business. Thus in asm, because you are aware of everything (and don't let the compiler do some of your work), you usually "design the algorithm different", even if you design it in pseudo-code, your "thinking" in low-level helps greatly. At least it does for me Wink

f0dder wrote:
When it was released for PC, it had "relatively high" demands for your video card though... assembly couldn't really help there.
Remember that just because something is implemented in hardware doesn't mean it's the best algorithm or design. I'm still waiting for the day that some software thingy with sneaky and spooky algorithms would draw faster than the hardware utilizing the current algorithms -- this doesn't mean software is faster, but the algorithms in hardware aren't God-like either, so I'm still dreaming of that day Smile (sorry about a little nonsense)

By asm I don't actually mean "hard-core CPU instructions, etc", but rather "low-level thinking" which is actually the most powerful reason for which i love low-level assembly

EDIT:
f0dder wrote:
From a quick google, it seems that NTSC has 525 scanlines and PAL has 625 - so 800x600 is probably a relatively fair comparison.
Funny I usually play my games in 800x600 or 640x480. I simply don't see a difference between 800x600 and other high resolutions.
Post 29 Jul 2006, 17:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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 vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.