Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I believe 6502 instruction set is a good first assembly language

nemanjatrifunovic.substack.com

Post reply on HN
Print view View original

281–290 of 297 posts

Re: I believe 6502 instruction set is a good first assembly language

#281

Post by [deleted] »

pcwalton wrote: post #253
adrian_b wrote: post #140

Earlier quoted context omitted.

RISC-V has been designed with the exact goal for being an ISA easy to implement in hardware, so that students will be able to do this. For this purpose, RISC-V is excellent. The RISC-V ISA has not been designed as an efficient method for encoding computer programs and even less for being easy to program in assembly language. When programming in assembly language, a complex ISA is bad, because one cannot hold in mind…

> I wonder if any of those who claim that the RISC-V ISA is simple can remember without searching the documentation how to implement the checks for integer overflow after each arithmetic operation. I mean, I can't give you the Hacker's Delight magic numbers for expressing integer division by a constant via multiplication on AArch64 or x86-64 off the top of my head either, but that's what we have compilers for. The fa…

[deleted]

Re: I believe 6502 instruction set is a good first assembly language

#282

Post by kazinator »

pcwalton wrote: post #253
adrian_b wrote: post #140

Earlier quoted context omitted.

RISC-V has been designed with the exact goal for being an ISA easy to implement in hardware, so that students will be able to do this. For this purpose, RISC-V is excellent. The RISC-V ISA has not been designed as an efficient method for encoding computer programs and even less for being easy to program in assembly language. When programming in assembly language, a complex ISA is bad, because one cannot hold in mind…

> I wonder if any of those who claim that the RISC-V ISA is simple can remember without searching the documentation how to implement the checks for integer overflow after each arithmetic operation. I mean, I can't give you the Hacker's Delight magic numbers for expressing integer division by a constant via multiplication on AArch64 or x86-64 off the top of my head either, but that's what we have compilers for. The fa…

Overflow checks is not what we have C and C++ compilers for, though. :)

Re: I believe 6502 instruction set is a good first assembly language

#283

Post by Lerc »

sususu wrote: post #216
crest wrote: post #118

I would argue that 6502 is a bad first ISA to learn if you want learn assembly. You‘ll spend most of your time fighting the quirks of this clever, but deeply flawed architecture. The idioms you learn to work around them don‘t translate to any better designed architecture that wasn‘t constrained by the tools and budget available to MOS at the time. If you want to learn a small, yet powerful instruction set with a few…

I kept thinking about the Ben Eater's 65C02 in a bread board series[1], is there any way to replicate what he is doing in his videos with an ARM CPU? [1] https://youtube.com/playlist?list=PLowKtXNTBypFbtuVMUVXNR0z1...

It wouldn't surprise me if you could do this with a RP2350, connecting GPIOs to the same location as the 65C02 does on the breadboard and even running emulated 6502 code.

It's totally not the same thing of course. A whole lot of transistors and clock speed go to making that feat possible.

Re: I believe 6502 instruction set is a good first assembly language

#285

Post by adrian_b »

camel-cdr wrote: post #230
adrian_b wrote: post #179

Earlier quoted context omitted.

The most important are the lack of integer overflow detection and indexed addressing. Integer overflow detection is required for any arithmetic operation unless it is possible to prove at compile time that overflow is impossible (which is possible mostly for operations with some counters or indices, whose values are confined inside known ranges), while indexed addressing is needed in all loops that access arrays, i.e…

> integer overflow detection What are you looking for here? Carry and overflow flags were explicitly not included because of the additional cost for OoO processors. Let's compare overflow detection on RISC-V vs aarch64: unsigned 64-bit: add: RV: add+bltu Arm: adds+bcc sub: RV: sub+bltu Arm: subs+bcs mul: RV: mulhu+mul+beqz Arm: umulh+mul+cbz unsigned 32-bit: add: RV: addw+bgeu Arm: adds+bcc sub: RV: subw+bgeu Arm: su…

The cost of providing carry and overflow is absolutely negligible in any CPU and even more so in an OoO CPU, which is many times more complex.

If you mean that if the flags are not stored in a general-purpose register, which is a possible choice, but it requires an extra register file write port, but in a dedicated flags register, like in x86 or ARM, then the flags register must also be renamed to allow concurrent operations, like any other register, this is a minor complication over having register renaming for all other registers.

What is extremely expensive is not having overflow and carry in hardware and having to implement software workarounds that require several times more instructions.

When loops are vectorized or you have an array of structures, this does not change anything, you still use the same indexed addressing (or auto-incremented addressing in ISAs that have it). Perhaps you think about scaled indexed addressing, which may not always work for an array of structures, but in such cases you just use simple indexed addressing, with the scale factor 1.

Without either indexed addressing or auto-incremented addressing you need an extra addition instruction for each memory access, which increases the code size and it limits the execution speed by occupying an extra execution port.

Because of this, the highest-performing RISC-V implementations have added non-standard ISA extensions for indexed addressing, but such extensions are still rather awkward because the base instruction encoding has not been thought for allowing indexed addressing, so the extensions must use a quite different encoding that must be squeezed in a limited encoding space.

Re: I believe 6502 instruction set is a good first assembly language

#286

Post by WillAdams »

crote wrote: post #203
WillAdams wrote: post #174

Why not learn a language intended for didactic use? https://en.wikipedia.org/wiki/MMIX has a quite deep corpus and what looks to be a good introduction: https://www.mmix.cs.hm.edu/getstarted.html (and I say that as a person who owns a much battered copy of Inman & Inman's _Apple Machine Language_)

Because there aren't any real-world implementations. Why bother with MMIX when you already know it'll never go beyond a toy "hello world" equivalent in an emulator? MMIX might be good for educational use in an academic setting, but literally anything else would be better if you want to have fun working with it. Nothing beats the magic of seeing your first program run on a real computer .

Unless your toggling switches at the front panel, I don't see this as a meaningful difference.

Re: I believe 6502 instruction set is a good first assembly language

#287

Post by markus_zhang »

gustavopezzi wrote: post #251

As someone who has been teaching assembly to undergrads for many years, I have a couple of things to say about this. First of all, I agree. The 6502 is great for beginners but that is not just merit of the 6502 language and I want to explain why. I have taught 68K, MIPS, ARM, x86, etc., and the overall good student feedback I got by teaching 6502 is mostly because of the surrounding context that comes with the CPU. T…

Gustav, thanks for giving us Pikuma.

Re: I believe 6502 instruction set is a good first assembly language

#288

Post by kazinator »

TheOtherHobbes wrote: post #132
brucehoult wrote: post #125

Earlier quoted context omitted.

That was never about the instruction set, it was more about the operating system -- or lack of one. As for modern CPUs and OoO etc, that's only about performance. The CPU, no matter sophisticated, must produce exactly the same results as the simplest in-order CPU. Hardware is never going to spill a register to RAM when you didn't write that. The maximum that is going to happen -- and this is pretty recent -- is that…

The performance is the point. 8-bit CPUs are so slow assembler could be - often had to be - hand-optimised for speed. You can't do that on modern CPUs, because the nominal ISA has a very distant relationship to what happens inside the hardware. The code you write gets optimised for you dynamically, and the machine is better at it than you are. You may as well write in a high-level language, because the combination of…

The original 68K instruction set is distant from modern computing only in these points:

- 32 bits

- lack of vectorization and such.

It's still perfect for most embedded stuff, by my estimation.

Well .... there are certain points like: wasn't there some issue with branch displacements on MC68K being confined to 16 bit ranges? If you have large functions, it can be a problem.

I dimly remember a project I was on circa 2001 to port a protocol stack (that we were developing on x86) to a system with some Freescale processor with a 68K instruction set.

I remember having to chop the source file into several translation units, because when it was all in one file, the inlining or static function calls or whatever, were generating PC relative branches that were too large for the opcode.

With today's hugeware, you'd be running into that left and right.

Re: I believe 6502 instruction set is a good first assembly language

#289

Post by brucehoult »

kazinator wrote: post #288
TheOtherHobbes wrote: post #132

Earlier quoted context omitted.

The performance is the point. 8-bit CPUs are so slow assembler could be - often had to be - hand-optimised for speed. You can't do that on modern CPUs, because the nominal ISA has a very distant relationship to what happens inside the hardware. The code you write gets optimised for you dynamically, and the machine is better at it than you are. You may as well write in a high-level language, because the combination of…

The original 68K instruction set is distant from modern computing only in these points: - 32 bits - lack of vectorization and such. It's still perfect for most embedded stuff, by my estimation. Well .... there are certain points like: wasn't there some issue with branch displacements on MC68K being confined to 16 bit ranges? If you have large functions, it can be a problem. I dimly remember a project I was on circa 2…

> I remember having to chop the source file into several translation units, because when it was all in one file, the inlining or static function calls or whatever, were generating PC relative branches that were too large for the opcode.

That's just inadequate tools.

With GNU as for RISC-V if I write `beq a1,a2,target` and target is more than 4k away then the assembler just silently emits `bne a1,a2,.+4; j target` instead.

Re: I believe 6502 instruction set is a good first assembly language

#290

Post by c64cryptoboy »

Dwedit wrote: post #71

The hairy part the 6502 instruction set is Subtract With Carry, and the confusion about how the carry flag works as a result of subtracting or comparing. SBC is implemented by adding the ones-complement (XOR FF) of the number or register. And the carry flag is backwards compared to other architectures, such as the Z80. On input, Carry Set means that you don't want an additional one subtracted, and Carry Clear means y…

The carry is certainly the most complicated flag on the 6502: https://archive.org/details/carryFlagCheatSheetV1.0
Post reply on HN