assembly? dying?

[Neo]

Or you could just get winrar which opens both zip and rar

WinACE has the following capabilities (amongst many other):

• compression of the following formats: ACE, ZIP, LHA, MS-CAB, JAVA JAR
  
• decompression of: ACE, ZIP, LHA, MS-CAB, RAR, ARC, ARJ, GZip, TAR, ZOO, JAR
  
• multi-volume (disk spanning) archives for ACE, ZIP, CAB
  
• self-extracting archives (SFX) for ACE and ZIP
  
• password encryption & recovery records for data protection
  
• Integrity check for ACE, ZIP, LHA, MS-CAB, RAR, ARC, ARJ, GZip, TAR, ZOO, JAR

Also popular today is 7zip...

[Zap]

Well, get that then

My point was that it's kinda silly to have something that doesnt work with one of the big formats.

[TheDarkJay]

Well, get that then

My point was that it's kinda silly to have something that doesnt work with one of the big formats.

I DO NOT HAVE MY OWN COMPUTER, I CANNOT INSTALL ANYTHING, MY CAPS LOCK IS STUCK

[TheBigBasicQ]

I'm with vongodric and jatos. Both have righty said, assembly will decline but wont die unless the CPUs executing those instructions die

[TheDarkJay]

Well, get that then

My point was that it's kinda silly to have something that doesnt work with one of the big formats.

I have never encounted any other format other than zip before, this is the first time i have EVER heard of rar or ANY other compressed format

[SBM Productions]

Computers may be getting quicker, but that shouldn't mean we can make older games with less optimization. It should mean we should be able to make better games with more optimization. asm won't die for the simple reason that speed will otherwise always be limited to how efficient the high level compiler is. Nothing optimizes better than the human mind. Therefore, the real shakers of the programming world will likely still know asm and use it to push their code to go faster. I'm pretty sure Carmack would've used some asm optimizations in doom 3.

[TheBigBasicQ]

yeah, ASM programming / skills will be rare but they wont die.

[helium]

Computers may be getting quicker, but that shouldn't mean we can make older games with less optimization. It should mean we should be able to make better games with more optimization. asm won't die for the simple reason that speed will otherwise always be limited to how efficient the high level compiler is. Nothing optimizes better than the human mind.

Think about JIT-compilers. They can optimize the code for the platform you run the program on. Hand written assembler can't.

[TheBigBasicQ]

helium, who exactly write those compilers? God? :lol:

[LooseCaboose]

Think about JIT-compilers. They can optimize the code for the platform you run the program on. Hand written assembler can't.

Errr, thats not what JIT compilers do exactly..

Assembly will always be around, it is necessary in writing the backends for compilers, low level drivers, etc. In normal application development, assembly is certainly dying. There are many reasons for this, firstly we are slowly moving away from directly compiled languages to technologies such as .NET and Java and machines are getting faster and have much larger amounts of RAM so there is less need for assembler optimisations.

I'm pretty sure Carmack would've used some asm optimizations in doom 3.

Not too sure about that, Doom 3 is written to be portable and most of the clever stuff is done with well researched algorithms. I have the source to both Quake (Windows version) and Quake 2, neither of which use any assembler code. If you look at Id's software though, they make extensive use of caching techniques, etc to improve speed in their games.

Hand written assembler optimisations are getting harder to achieve these days as machines become far more complex. Some of the optimisations used these days include: strip mining, loop blocking, write-combining and pipelining stuffing, many of these techniques are able to be done by compilers but can be very difficult by hand. Some of the optimisations require knowledge of the cache and cache line sizes, which means that the assembly code will be different on different machines in the same family.