> FASM 1
If you wanted FASM g for arm(apple silicon) or something that might be much more achievable. FASM g was designed to be much more multiplatform.
I switched to FASM when I started playing with MenuetOS [1] years ago. I like FASM, and the community was very helpful then.
I started with 6502 assembly back in the 80s, and assembly for 8-bit micros in the 90s. I left assembly until just 4 years ago, and then I started playing with it again for boot sector games because of Oscar Toledo Gutierrez's book, 'Programming Boot Sector Games', for fun. Now there's, 'More Boot Sector Games'.
I was a Commodore PET 2001, Vic-20, Amiga 1000, Amiga 500, and Apple PowerPC user back in the day (1978 to 1997), but it looks like DOS/Gates has won; here I am spending my free time trying to create games for DOS!
NOTE: Legacy boot mode was taken out of Windows around 2019/2020, so you will need an older computer if you want to boot it off of a USB stick. Or you could just use a DOS emulator.
Would you agree that it makes more sense though? I tend to agree with you, I _want_ to write 'mv src, dst', but the other way around has some strong supporting reasons:
- it's closer to the usual pseudo assembly "eax <- ebx"
- it's closer to the mathematical "A = B"
- on a more practical side, it's what was adopter by C standard library "memcpy(dst, src)"
Thinking about it, there are more reasons to favor 'mov dst, src'. I think the culprit (at least for me) is that I cannot "pronounce" it correctly in my head. I have to use some peripheral sentence such as "move in dst the contents of src" instead of the more natural (but backward from the reading perspective) "move src to dst"
Either works for me, I'm easy. Besides I cut my teeth on m68k and x86, and I do like how it keeps it easy with things like mov.b, mov.w and mov.l - keeps things clear what you're working with.
I had to use a bit of assembly recently and chose nasm for it. A client had an older piece of compiled code and wanted to be able to use it on a modern machine. It was written in a propriety language and compiled for a 32bit system. The argument passing conventions used by the compiler were unusual. So I wrote a bit of assembly in nasm to create a stub function callable from C, it was really just moving things into the right registers and some bits to the stack. So nothing really being done in the asm. The hard part was figuring out the calling convention.
Edit: Looking back it turns out that "recently" was 18 months ago.
I'm starting to learn reverse engineering and while doing that I have had to read a bunch of assembly but also write a small amount too. I don't use NASM and am only writing a few instructions at a time, mainly either updating an existing instruction or replacing an instruction with one or more that are the same size
Nasm was news at a time when it would make sense to call an open source project the netwide something.
For this I just remind myself that every year there are people younger than me who are getting their start in these topics and this is their first time hearing about nasm. That's ok.
At my job we use nasm to assemble the x86 entry points for our OS kernel. Any assembler would do the job - someone before me just happened to pick nasm.
nasm SDK is really scary: tons of tough-to-read perl scripts for code generation. I would stay away from it, but nasm is used in ffmpeg. I prefer to use fasm instead, even though its extremely powerful macro language is an invite for abuse.
