C-Based languages

C is an amazingly designed language.  It's beautiful, simple, elegant and fast.
Everything a well designed programming language should be.

C++ then came along and shit all over Dennis Ritchie's masterpiece.  Bjarne took a beautiful, simple, elegant and fast language. And kept shitting on it until all that was left was 'fast'.  Dennis should of beat the shit out of him for turning his work of art into an abomination.

Then Gosling came along, surveyed the turd that Bjarne had dropped, and attempted to clean it up.    He redesigned C++ to remove the crap and attain the elegance that C had.  Unfortunately, in his cleaning frenzy, he over-simplified the language and sacrificed speed.  In the name of simplicity he removed pointers, manual memory management,  generics, operator overloading and native code compilation.  A noble effort, but ultimately just as much of a failure as C++.

>>80
So your code coincided with the optimized code in this case, maybe nasm thought your 7 instructions weren't worth optimizing since it would take longer to do that than it would for you to run it a billion times, maybe it recognized your program as rubbish, so what is your point exactly?

Try doing this with a large code base, I'm sure the flag is there for a reason, and not to mention that there are several other optimizing assemblers out there. You should try searching for "optimizing assembler" with Google, I'm certain that despite your apparent disabilities you will still be able to operate a simple search engine like Google.

And to expand on that, the -Ox flag in nasm picks smaller encondings.
Example:
Instead of assembling add ebx, 3 as add r32, i32 it assembles as add r32, i8.
Proof:
_start: add ebx, 3
No optimization:
00000000  6681C303000000    add ebx,0x3
Optimization:
00000000  6683C303          add ebx,byte +0x3

>>81
It didn't because it's not nasm's work. -Ox only does >>82, and it's even written in the fucking documentation.
The burden of proof is on you, you are the one claiming there exists such an assembler.

>>83
I'm not really interested in convincing you that optimizing assemblers exist, the proof is even in this thread, >>72 provides you with a handy link and >>82 shows that nasm does produce "optimized" output so it is an optimizing assembler, and as I said it's fairly easy to operate Google and I'm sure even you can figure out how to do it.

If you still don't want to admit that optimizing assemblers exist I don't care, I generally don't bother dealing with retards like yourself.

>>83
if it doesn't exist, you could always make one. I don't get what you all are so worked up about.

>>84,85
Listen you stupid faggots assemblers should only translate the assembly into the exact equivalent opcodes. ALso still you have to come up with any proof that such optimizing assemblers exists.

>>85
Because it's not useful and the assembler cannot infer the intent of an apparently useless instruction and might ``optimize'' away something important.
Assembly is not C, where the compiler holds your hand making you think ``omg im writing low level coeds i can totally see wat teh machine is doing!!! :D'' while it reduces your whole loop to three SSE instructions and makes your undefined behavior ridden code go fast.
When I write assembly code, I expect my opcodes mnemonics to be assembled to said opcodes.

>>87
When I write assembly code, I expect my opcodes mnemonics to be assembled to said opcodes.
Then you shouldn't use an optimizing assembler. It's that's simple, just relax.

>>84
A peephole optimizer would have optimized the assembly in >>80 to a single mov eax, [ebx], wouldn't it?

The reason why an "optimising assembler" in the same sense of optimisation as a compiler does not exist is that at the Asm level it is impossible to determine in general whether or not an instruction is needed. The extra instructions could be deliberately inserted for timing purposes, testing, etc. (This is a similar situation to how compilers may remove delay loops completely as they do not compute anything, and thus should not be used for the benchmarking of hardware.) On the other hand a compiler for e.g. C can eliminate code it deems unnecessary as the programs' outward behaviour with respect to the machine model defined in the language's standard remains unchanged.

Taking advantage of shorter encodings for instructions (like >>82 and the well-known short/medium/long jumps) is a default for many assemblers and it has been this way since the 8086 was introduced. That type of "optimisation" does not change the behaviour of the program at the machine level, but only its size. Going beyond that requires deeper analysis that no publicly available assembler I am aware of can do.

(Before some of you attempt to refute with this point: I am aware that some advanced techniques like SMC will be affected by this type of optimisation. However all assemblers I have used allow explicit specification of the form of instruction you want, or failing that, directly specifying the bytes that constitute it.)

>>80
66
Why are you using 16-bit mode with 32-bit instructions?

>>89
No. You forgot about the stack.

>>63
Just don't use the features that are too bloaty.

>>67
They need to improve their code generator. As-is, it's probably the extremely simple single-pass type, with very few rules. The patterns are obvious: It almost always uses eax and edx for transfers, and ebx for the first pointer dereference. Occasionally it will use esi and edi for loop counters. Besides the loop counter exception, it does not seem able to keep track of register values beyond more than 3-4 instructions at most (likely expression boundaries).

>>20
We've almost reached the physical limits of hardware. That's why you see systems getting wider. But not everything can be parallelised. I've recently worked with some cloud/distributed systems stuff written in Java, and despite what they say, the efficiency is horrible. A C/C++ rewrite could easily cut memory usage and execution times to 1/10th what they are.

Another example: look at boot times of various operating systems over the year when run on their recommended hardware configuration. If there has been improvement, it is nothing near the order-of-magnitude growth in speed that processors have had for the past 2 decades. Faster hardware enables us to do more; but at the same time, also entices us to waste it. In other words there has been growth at the "top edge" of productivity, but the "bottom line" has remained essentially unchanged. MS has been aggressive in marketing the boot speed of Windows 7 and Windows 8, but to get those "improvements" they had to remove a lot of the existing functionality in previous versions. Does that fit with the notion of hardware being faster? "Do less with more" is where things seem to be going with software these days, and it is only to create the illusion that things are improving. As Apple's success shows, with the right marketing you can turn anti-features into features perceived by the masses of mindless consumer drones.

This level of waste is not sustainable --- look back to the 1970s energy crisis (were you even alive back then?) --- "let's waste resources because they seem infinite for the time being" was the attitude people had before then, and it didn't result in anything good.

>>91
Why are you using 16-bit mode with 32-bit instructions?
Nasm for DOS.
No. You forgot about the stack.
Oh, right, there's an extra push in there.
mov eax, [ebx]
push eax
, then.

>>44
nice dubz bro

>>1
Java is actually one of the fastest languages out there and it also has a very clear syntax. Using a fucklot of resources doesn't mean something is slow, but yes, it's a very bad thing. And objects are not even forced on you, only retarded code monkeys ``abstract" everything.

Java is slightly better than C++ for making small projects, as long as you don't fuck with the standard library.

So please stop pulling shit out of your anus, Java is not a complete failure.

>>94
And objects are not even forced on you,
That's why everything mustn't be in a class in Java.

>>95
Classes are not objects, this isn't Smalltalk bro.

>>96
downvoted

>>97
upvoted

>>99
dubscheckem

100 get

>>99
nice dubz doode

>>96
Yes they are, they are just instances of the metaclass.

>>7
Fuck off back to /g/, ``please"!

FWIW (Turbo) Pascal is actually better than C:

* faster
* cheaper to maintain
* conceptually simpler

The only reason it didn't catch on is because of pig disgusting eunichs

>>103
No wonder it's Turbo.

>>101
Oh really
public class IsClassInstanceofObject {
  public static synchronized final strictfp void main(String[] args) {
    System.out.println(Class instanceof Object);
  }
}
$ javac IsClassInstanceofObject.java
IsClassInstanceofObject.java:3: error: illegal start of expression
        System.out.println(class instanceof Object);
                           ^
IsClassInstanceofObject.java:3: error: not a statement
        System.out.println(class instanceof Object);
                                 ^
IsClassInstanceofObject.java:3: error: ';' expected
        System.out.println(class instanceof Object);
                                                  ^
3 errors

>>105
If you were going to fabricate error messages, you could at least get the casing right.

>>106
The uppercase C was a typo. The errors are correct.

C is the best programming language, and I think we should force everyone to learn it.

>>108
Too obvious, IHNBT.

>>105
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html

check my trebs bro yo

>>39
EEfag here. We use C and assembly, and nothing else. Most EEfags suck balls at both though.

>>109
Ha ha, only serious.

GAWWZMACS FLABBERGASTS MY AUDIENCE