2026-05-03 15:39:56 veltas: i was trying random z80 emulators because i wanted to learn a bit of assembly, but ended chosing arm since that's what i already have and i can just use as and ld instead of having to emulate anything 2026-05-03 15:42:48 i was following this tutorial btw 2026-05-03 15:42:52 https://youtube.com/playlist?list=PL2EF13wm-hWAlQe87UB2HV0SVhBXFpXbn 2026-05-03 15:43:04 and also a book which seems cool 2026-05-03 15:43:40 modern assembly language programming with the arm processor 2026-05-03 15:48:19 have you also checked risc-v assembly? 2026-05-03 15:50:43 no 2026-05-03 15:52:38 i was looking at mips also 2026-05-03 15:53:26 arm is the present anyways and is what i have so it made sense to just use what have and get started 2026-05-03 15:54:13 also that book seems to assume linux and gnu assembler, which is exactly my setup 2026-05-03 15:55:15 i would like to end making some sort of emulator to really grasp assembly 2026-05-03 18:04:34 vms14: The real difference between assembly and higher level programming is just the very limited action of any one step. You move a value from one place to another (between two registers or between register and RAM), etc. Anything more complicated you need to do you have to build up out of those simple little steps. But there's nothing terribly mysterious about it. It's just tedious. 2026-05-03 18:14:05 KipIngram, one might say that assembly has a one to one correspondence with the cpu opcodes ? 2026-05-03 18:15:10 and that HLL does not as it may generate many opcodes with one instruction ? 2026-05-03 18:37:01 Sure - that's a fair statement. It's also worth noting that aside from register names the "names" you use in an assembly programs more or less always refer to RAM addresses. Any structure beyond a single RAM location you have to build up from constituent pieces. 2026-05-03 18:37:21 You do also have macro names, but that's sort of an extra level. 2026-05-03 18:37:54 If I were first setting out to understand assembly I'd leave macros out of it initially. 2026-05-03 18:39:17 yeah, macro assemblers were an improvement over the plain assembler I guess 2026-05-03 18:40:18 all this is fresh in my mind because I started rereading 'thinking Forth yesterday during a all day scheduled power outage 2026-05-03 18:41:10 then I moved on to the book 'experimental methods in RF design' 2026-05-03 18:41:38 so I spent the day reading, or trying to in gloomy overcast light 2026-05-03 18:43:12 it's interesting, when reading tech related books now, 99% of them make perfect sense, Im rarely confused by anything 2026-05-03 18:44:54 and now Im back to constructing a 3 winding, transformer SPICE model for xschem, following AI advice on the process 2026-05-03 18:46:30 each winding has a centretap, so that requires 6 model inductors, each with mutual coupling statements 2026-05-03 18:47:33 AI is really excellent as a tutor for this kind of thing, advising the correct steps of a proceedure 2026-05-03 19:04:00 Macro engines have gotten pretty good - initially they were just shortcuts for a fixed set of instructions, but later they developed parameter capability and so on - it's almost like a little baby programming language itself. 2026-05-03 19:04:40 Comes in really handy for Forth - you can craft a set of macros that pretty much automates your dictionary construction. It can really help tidy up a system that winds up spreading things out in RAM in various ways. 2026-05-03 19:05:13 But I do think that should be tackled AFTER you get the basic sense of working at the assembly level.