Software-update: Nasm 2.07

Assembly, een van de oudste programmeertalen, wordt tegenwoordig vaak gebruikt voor het optimaliseren van toepassingen. Nasm kan assemblycode omzetten naar verschillende binaire objectformaten zoals elf, coff, Mach-O, win32 en win64. De programmeurs hebben de ontwikkeling van Nasm weer stevig opgepakt, waardoor er inmiddels ondersteuning voor x86-64 en sse3, 4.1, 4.2 en 5 is toegevoegd. Versie 2.07 van Nasm is enkele dagen geleden uitgebracht, voorzien van de volgende lijst met aanpassingen:

Version 2.07:

• NASM is now under the 2-clause BSD license.
• Fix the section type for the .strtab section in the elf64 output format.
• Fix the handling of COMMON directives in the obj output format.
• New ith and srec output formats; these are variants of the bin output format which output Intel hex and Motorola S-records, respectively.
• rdf2ihx replaced with an enhanced rdf2bin, which can output binary, COM, Intel hex or Motorola S-records.
• The Windows installer now puts the NASM directory first in the PATH of the "NASM Shell".
• Revert the early expansion behavior of %+ to pre-2.06 behavior: %+ is only expanded late.
• Yet another Mach-O alignment fix.
• Don't delete the list file on errors. Also, include error and warning information in the list file.
• Support for 64-bit Mach-O output.
• Fix assert failure on certain operations that involve strings with high-bit bytes.

Version 2.06:

• This release is dedicated to the memory of Charles A. Crayne, long time NASM developer as well as moderator of comp.lang.asm.x86 and author of the book Serious Assembler. We miss you, Chuck.
• Support for indirect macro expansion (%[...]).
• %pop can now take an argument.
• The argument to %use is no longer macro-expanded. Use %[...] if macro expansion is desired.
• Support for thread-local storage in ELF32 and ELF64.
• Fix crash on %ifmacro without an argument.
• Correct the arguments to the POPCNT instruction.
• Fix section alignment in the Mach-O format.
• Update AVX support to version 5 of the Intel specification.
• Fix the handling of accesses to context-local macros from higher levels in the context stack.
• Treat WAIT as a prefix rather than as an instruction, thereby allowing constructs like O16 FSAVE to work correctly.
• Support for structures with a non-zero base offset.
• Correctly handle preprocessor token concatenation (see section 4.3.7) involving floating-point numbers.
• The PINSR series of instructions have been corrected and rationalized.
• Removed AMD SSE5, replaced with the new XOP/FMA4/CVT16 (rev 3.03) spec.
• The ELF backends no longer automatically generate a .comment section.
• Add additional "well-known" ELF sections with default attributes.

Version 2.05.01:

• Fix the -w/-W option parsing, which was broken in NASM 2.05.

Versienummer	2.07
Releasestatus	Final
Besturingssystemen	Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, DOS, macOS, OS/2, Windows Vista
Website	The Netwide Assembler
Download	http://www.nasm.us/pub/nasm/releasebuilds/2.07/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (5)

[siepeltjuh]

Welke tweakers hier gebruiken dat eigenlijk?

Leveren deze optimalisaties nog erg veel op? Zelf gebruik ik uitsluitende talen als C# en java. Dat gaat voor mijn gevoel zo veel makkelijker. En ach de snelheid is met wat ik bouw niet zo boeiend dat het op nanoseconden aankomt.

[SKiLLa]

Voor het serieuzere low-level ontwikkelwerk zoals drivers, 3d engines, etc. wordt meestal C++ gebruikt, soms met een stukje assembly erin voor hele tijdkritische loops.

Niet zozeer dat compilers slecht werk afleveren, maar het is als CPU vs GPU, generiek vs. specialized. Is een C++ compiler een sportieve straatauto met airco, airbags en een radio, dan is assembly de hardcore formule-auto met uitsluitend een rollcage.

Bijvoorbeeld de file-compression van Windows is een stukje hand optimized assembly, en veel distributed computing (en andere rekenkundige) projecten bevatten getweakte assembly. De snelheidswinst kan enorm zijn (door micro-optimalisaties voor de CPU architectuur), maar de toepassing is inderdaad erg beperkt, de "kostprijs" van assembly schrijven, tweaken en onderhouden is vele malen hoger dan van C++, laat staan Java of .Net.

[oeLangOetan]

Er zijn nog steeds geen C compilers die deftige SMID code kan genereren, autovectorisatie is een erg lastig probleem, asembler of compiler intrinsics zijn de enige opties in dat geval. Dit is vooral om dat C deze datatypes slecht ondersteunt.

Over het algemeen (dus met uitzondering van het bovenstaande geval) schrijf je beter C dan assembler voor de huidige moderne out of order cpu's, handmatige optimalisaties maken op die architecturen meestal niet veel uit & compilers produceren zeer goeie code.

Veel embedded cpu's hebben een eenvoudige in-order architecuur, waardoor het interessanter is om asm te gebruiken en je zal meestal efficiëntere code dan de compiler kunnen bedenken.

[Verwijderd]

section .text
global _start ;must be declared for linker (ld)

_start: ;tell linker entry point

mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel

mov eax,1 ;system call number (sys_exit)
int 0x80 ;call kernel

section .data

msg db 'Hello, tweakers!',0xa ;our dear string
len equ $ - msg ;length of our dear string

[YaPP]

haha heel nice

Voor degene die het niet doorheeft waar die code op slaat... Zo schrijf je in assember

#include <linux/syscalls.h>

sys_write( 1, "Hello, tweakers!\n", 17 );
sys_exit();



en ja, geen printf() of exit() hier.. dat is de laag die libc bovenop de systeem calls plaatst.