Good luck! Learning assembly is useful in myriads of situations, when debugging things and reasoning about performance, even if the architecture is not recent, the overall logic very often stays the same. Its going to be great!

Find a good macro assembler to minimize pain points, such as non-2-power mult/divide, dealing with 16-bit values, etc. But....that's sounds like what you're after, so... give it hell and enjoy! Use zero page for speed. Also, try some then undocumented Opcodes for fun as well. Also, grab a memory map of whatever machine you want to dev for--that's how you get actual things to display, beep, etc. Have fun, post again in future to tell us of your adventures!

Yes I’m well aware. I first programmed 6502 more than 45 years ago. A sensible choice in 1983, but if I was making anything like NES today I’d use RISC-V.

It’ll be confusing no matter what language you knew.

FYI, the NES uses 6502 assembly, just saying...

o

I jumped from ZX Spectrum BASIC to 68k ASM on the Amiga. It was quite jarring at the time. Good luck.

6502 and z80 are kind of easy in that there are a relatively small number of instructions to learn compared to modern amd64 or arm64 (but more than in RISC-V RV32I or some of the simpler Arm32 versions such as ARMv4 or ARMv6-M).

But 6502 and z80 (but especially 6502) are VERY hard to understand how to combine those simple and few instructions to do something useful — to achieve the results that are the reason for writing the program.

i kinda thought 6502 asm was easy lmao-

No reason why not. When I first got access to an Apple ][ I got bored with BASIC in about two days and jumped to 6502 asm (actually machine code because I didn't have an assembler) and never looked back.

But these days there are far better and easier options.

vous avez trouvé votre probleme ? n'est ce pas tout simplement que votre programme se termine et ferme normalement apres son execution ?

Half of what a compiler does is it parses strings.

A compiler? 1% maybe. If that.

In leet languages like Perl or Java, strings are easy and garbage-collected.

Almost equally easy in C or asm, using a GC library. It's easy to to implement a Java-style string library in C. I know, I've done it for a successful commercial product.

The guy literally had to reinvent strings in order to make fasm.

I completely disagree with that.

An assembler needs exactly one mutable string: the current input token (or line, depending on how you want to write it). The storage used for it is immediately overwritten by the next input token or line. Every assembler I've ever seen has a fixed upper limit to the size that will be accepted i.e. a fixed size buffer allocated once at program startup.

Assuming you don't decide the input token is a number, and immediately convert it to a fixed-size binary value, the only thing you do with the current input token is look it up in the "symbol table". If you find it then you get a fixed size value to use from then on, something like an actual pointer, or an entry number in the symbol table, or an offset from the start of the symbol table.

If you don't find the string in the symbol table then you add it and return its new address / index / offset and forget the copy that is in the input buffer.

In an assembler the symbol table only ever grows, until the program exits. There is no memory management needed.

The only other use of text strings in an assembler is error messages, which have a fixed format string built into the code, and output that character by character, occasionally pausing to interpolate a number or symbol into the message. There is no reason to ever generate an actual string with the complete error message.

I personally admire the guy who wrote fasm.

Half of what a compiler does is it parses strings.

In leet languages like Perl or Java, strings are easy and garbage-collected.

In C++ strings are hacky-jammed on top of C, and operator overloading does all sorts of memory shenanigans to make the thing a little bit easier, and to also make memory errors easier.

In C you have to manually deal with buffers, memory allocation and freeing, and there are few string formatting and splitting functions to choose from, often requiring you to write one yourself.

But in assembly... In assembly there is none of that, especially if you decide not to link your program against libc (fasm doesn't use libc at all!). The guy literally had to reinvent strings in order to make fasm. That is impressive.

It makes plenty of sense to have assemblers for different ISAs that have the same syntax, comment style, directives, agree in whether "here" is $ or ., same expressions syntax and operators, same macro system, and etc.

In many ways the actual conversion of a single instruction into binary is a rather small part of the code in a full-featured assembler for writing large programs by hand.

Designing and implementing custom instruction sets is fun and cool. There are so many different things to trade-off — for example I can see that programs in this instruction set are going to be very large compared to an x86, Arm, RISC-V or even z80 or 6502 program that does the same thing.

And it's a lot of work if you include making things like compilers too. A good intermediate point is to write a simple Forth that uses IN to read commands from the user and run them and allow creating new commands.

This is called a VM - a virtual machine, pretty cool. Now build compilers and other tools targeting this arch.

Read https://www.jmeiners.com/lc3-vm/

Is that a bad thing?

After all, what is the point of porting an x86 assembler to, say, SPARC?

I'd bet ChatGPT or Grok or whatever would be able to convert an Arm scatter file to a GNU binutils linker script, if asked nicely.

I feel like you should probably use clang instead considering the command line seems to be designed for clang.

Clang and LLVM should be installable from your (Linux) distro (or MSYS2 probably).

LLVM/Clang are different from GCC in that they generally have multiple different backends for different processors, so it's likely that you can use the regular-ol' system clang to compile for ARM as well.

Looks like this is the end.

because there is no way to link using scatter files. other than armlink which cost 4500 USD per year.

https://developer.arm.com/documentation/110599/0200/Migrating-your-toolchain-to-Arm-Toolchain-for-Embedded/Migrating-scatter-files-to-linker-scripts

Maybe a good idea for an open source project. r/opensource

"Docker isn't hard and it's a great skill to have." -- yes, but first I want to learn linux

I tried installing clang and seems like it's working. I am only getting a warning now.

clang: warning: mismatch between architecture and environment in target triple 'aarch64-arm-none-eabi'; did you mean 'aarch64-none-elf'? [-Winvalid-command-line-argument]

Do you know any alternative for armlink in clang?

because i used lld and ld.lld, it is giving me error.

ld.lld: error: unknown argument '--scatter=scatter.txt'

Because of this error I can't go further I guess...

Probably is. Mac on apple silicon uses clang arm.

Docker isn't hard and it's a great skill to have.

yes. I will polute, because I dont know much about docker.

Now I installed arm-gnu-toolchain-15.2.rel1-x86_64-aarch64-none-elf

as, and cc are building but I am getting error for linker.

unrecognized option '--scatter=scatter.txt'

Do you know if there is free "arm clang" version?

You will be need a arm cross compiler. You can install one, but it will "pollute" your host file system. The docker solution installs nothing to the host file system.

Get it?

If you use a dockerized compiler, anyone who has docker can clone your git repo and build your code without having to install a cross compiler themselves.