Suggestions for a microcontroller (general-purpose) - Page 1
Forum section: electronics / general

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 02:59:31 am
content: Let's say a guy who last worked with microcontrollers (a Ubicom SX-28) about a decade ago, and now wants to start playing with one again. Question is, which one?I've thought about something like the AT-Tiny or equivalent. But there are so may choices available, it's quite confusing.Here's what I'd like to have:8- or 16-bit controller (maybe even 32-bit later on)Real-time clock/counterUSB programming (I guess almost everything uses this nowadays?)Programmer with ZIF socketBasic IDE that runs under Windows: assemble/link/run from PC; maybe a debugger, though not necessarySeveral I/O portsAbility to use interrupts and to create my own ISRsModerately fast; speed not crucial, but at least many MHz would be niceDecent amount of program & data memoryLikely to remain available and supported in the forseeable futureI want to program in the μc's native assembly language, not C or C++. The IDE would let me create and use my own libraries (or I could simply create separate object modules), or I could simply put everything in one source file.The IDE wouldn't even need to have its own editor (though it probably will): I have my own that I use for programming.So what would y'all suggest? Oh, and $inexpensive$ would be nice.

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2025, 03:29:09 am
content: You really need to define your terms.The only concrete thing you're said is "ATtiny".As far as I know, ATtiny maxes out at:- 32 pins on ATtiny 48, 88, 828, otherwise 24 or fewer- 3k bytes RAM on ATtiny3224/6/7, otherwise 2k bytes or fewer.- 32 KB program memory (flash) on ATtiny3216/7/24/6/7, otherwise 16 KB or less- maximum 20 MHzAnd 8 bit, obviously.The bigger ones cost something like $1.30.Looking at those specs, how would you feel about:- 32 bit- 48 MHz- 2 KB RAM- 16 KB program flash- 8 to 20 pins- $0.10 to $0.20

author: ledtester
author_rank: Super Contributor
timestamp: March 07, 2025, 04:05:36 am
content: I would look at the Raspberry Pi Pico and the W-version for wifi and BT radios.- dual core, lots of memory - both RAM and flash, fast, decent amount of GPIO, standard DMA and timers plus the programmable IO blocks which people have done some amazing things withAlso - it is very easy to program - it can appear as a mass storage device so you just drag-and-drop files to program it. You can actually use flash as a file system which your applications can access.In addition to C/C++ it can be programmed in Micro Python which can be fast enough for a lot of things like experimenting, prototyping and avoids the complexities of C.Lots of hobbyist support.

author: Smokey
author_rank: Super Contributor
timestamp: March 07, 2025, 04:11:51 am
content: Professional use that might end up in products:For a full range of parts within the same development environment, I'd say STM32 stuff. People complain about CubeMX and CubeIDE, but it's a full featured thing supported by a big company that doesn't routinely make breaking changes to stuff and will be around for a while (and isn't Chinese, which is relevant for a few reasons these days).For hobby stuff:Whatever was used by whatever project you are copying and already has working code somewhere.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 04:48:54 am
content: Please keep in mind that I want to program this in assembly language, not C or Python or whatever.Just my preference.And yes, this is for hobby use, not production. But I don't want to just follow an instructable or someone else's design and use whatever they used: this is for my own li'l projects.

author: Smokey
author_rank: Super Contributor
timestamp: March 07, 2025, 05:15:22 am
content: I'd still pick stm32 stuff. Just in case you change your mind and actually want to finish a project then the c dev environments will be there waiting for you ready to go :⁠-⁠)If it's not for a product and you don't care about cost or dev tools, then just about anything is on the table and I can't say why one would be better than another.Actually maybe you might want to use 8051 stuff since that's been around from the old days when people still used assembly. You could find an old library books that has asm examples code.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 05:28:40 am
content: Well, just for ha-has let's say a guy wanted to investigate going the 8051 route: what would a guy do for a programmer? Are there USB programmers for that processor? I wouldn't guess so.Point is, I need a package: microprocessor, programmer & IDE (basically Windows software to run the programmer). Doesn't have to be anything fancy.If a programmer is easy enough to build (including the software to drive it) I might could do that.

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2025, 05:33:12 am
content: Quote from: Analog Kid on March 07, 2025, 05:28:40 amEven our host managed to work out the MCU, at a similar level to ATtiny, but much cheaper I was alluding to.

author: Smokey
author_rank: Super Contributor
timestamp: March 07, 2025, 05:36:22 am
content: Looks like Atmel/Microchip have a whole series of 8051 stuff (at89) with all sorts of programmer options from uart bootloader to spi to jtag.

author: RoGeorge
author_rank: Super Contributor
timestamp: March 07, 2025, 06:03:35 am
content: Buy any Arduino. Use assembly instead of C. Anything that can be programmed in C or Python can be programmed as well in assembler. See in this search results which one you like:https://duckduckgo.com/?t=ffab&q=arduino+in+assembler&ia=webAlso, writing in assembler is a futile exercise these days. That was a thing 30+ years ago. Nowadays C optimization is very good, and the ratio between speed vs memory optimization can be changed with a simple compile switch.

author: IOsetting
author_rank: Regular Contributor
timestamp: March 07, 2025, 07:11:14 am
content: I would recommend stm32, which covers both hobbyists and professionals, the toolchains and hardware are affordable, no knowledge will be wasted, no significant challenges in near future (if there are any, it might be risc-v).

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 07, 2025, 07:29:54 am
content: If you really want to stick to assembler, the AVR based MCU's (ATtiny - ATmega) will be easy to use. A USBASP will be very useful for working with them.https://www.aliexpress.com/item/1005006827605143.htmlThe 8051 core based MCU's are also an option, but I don't know about how to program the more modern versions. My experience with them is from way way back and used UV erasable EPROM's to hold the code. Did write in assembler. But now that I'm using C to work with the more modern MCU's I would not dream of going back to assembler to write a full program.The STM32's or Raspberry Pico recommended by some are 32 bit ARM based and very powerful, but learning the full width of the assembly language takes quite some time, in which one can easily learn C or micro python. I myself would choose C, because it allows you to use many different MCU's with even the ones with small memories.Quote from: RoGeorge on March 07, 2025, 06:03:35 amI fully concur with this. Don't be a dinosaur and move on to learn C, unless assembly is what you grave of course.

author: peter-h
author_rank: Super Contributor
timestamp: March 07, 2025, 08:12:05 am
content: How cost sensitive is this?If you can afford say $5 them go for arm32. These chips (I am using STM 32F417) do basically everything for most products including USB and ETH. And you will save yourself a huge amount of work re-doing every new product or version.

author: voltsandjolts
author_rank: Unknown
timestamp: March 07, 2025, 08:21:55 am
content: QuoteMost microcontrollersaregeneral purpose. Take your pick.

author: phil from seattle
author_rank: Super Contributor
timestamp: March 07, 2025, 08:24:56 am
content: Just about every micro out there can be programmed in ASM. I don't think that is a limitation.I'd skip 8 and 16 bit micros and go straight to 32 bits. My current favorite is the RP2350 or RP2040. The RPi Pico (RP2040) costs all of 4 bucks, there is a WiFi version for a buck more, programs via USB, has in circuit debugging and has several tool chains (including Arduino). And as a bonus, you can get custom boards made for a very reasonable amount if that's something might want to do. I've used just about every micro out there and love the simplicity of the RP series. One of the really cool things about the RP family is programmable I/O (PIO) - basically little general purpose programmable I/O finite state machine processors that allows hardware control independent of the CPU. It can be a serious performance boost over non-PIO implementations. The RP2040 has 8 and the RP2350 has 12. We use them in a motion controller application to significantly boost the step rate to servos and avoid use of a second timer.As to the 8-bit 8051, way long in the tooth (~45 years old). Perhaps venerable is a kinder term. Used for embedded cores in all sorts of controllers. It available as a soft core in VHDL and Verilog. Also for FPGAs. Good skill to have in certain job categories. But, again, I'd skip 8-bit and to go to 32.

author: Picuino
author_rank: Super Contributor
timestamp: March 07, 2025, 09:05:02 am
content: Why would you want to program only in assembler? That's going to limit you a lot on larger micros (16 and 32 bit).Nowadays it is much better to program in C and leave assembler for small optimized routines or access to special instructions.I would advise you to look for micros from the old Atmel (now Microchip). Not the attiny range, but the atmega and above.Here you have some tools to search for micros:*https://www.microchip.com/maps/Microcontroller.aspx*https://www.microchip.com/en-us/parametric-search/980

author: woofy
author_rank: Frequent Contributor
timestamp: March 07, 2025, 09:29:51 am
content: Jump straight to 32 bit. Forget 16 bit. 8 bit is worth considering when it has peripherals needed for a project.My advice, go STM32.Buy yourself a nucleo board, download the free CubeIde and your away.https://www.st.com/en/evaluation-tools/stm32-nucleo-boards.htmlBut really, do some research on different microcontrollers, what ISA interests you? The SX-28 was a PIC look-a-like. If you can get your head around that architecture, you should have no trouble with most controllers.

author: newbrain
author_rank: Super Contributor
timestamp: March 07, 2025, 09:35:14 am
content: I'll add my two cents, and also advice going Arm or maybe RISC-V.If you go the Arm way, the RP2040 (RPi Pico) is aCortex-M0+ core, with a very simple instruction set (see the attached picture) and none of the traps for old players more sophisticated Cortex-Ms have, but still quite powerful.A regular instruction set (quite RISCy), plenty of memory, many general purpose registers, HW multiplication, etc. etc.For the full core documentation,Arm pages are the best.You mentioned writing your own ISRs, an advantage of the Arm architecture ISRs are exactly like any other function, no need for special return instructions or prologues and epilogues, the CPU will stack all the registers for you and pop them out automatically.The ABI to interface with libraries written in C is quite rational and simple.Don't let the fact it's 32 bits deter you, it just makes things easier.Instruction are 16 bit wide (Thumb2), possibly followed by a 16 bit operand.RP2040 peripherals are not that crazy to program, and cover all the basic needs and some advanced ones with PIO - another assembly language in itself!Documentationis half decent (IMO, worse than STM32, but better than others).Pico boards are so cheap it's a no-brainer, if you don't like the experience, you are out of only a few dollars.A (DD)Go(ogle) search brings up many results with info on how to use assembly on an RP2040.Pico2's RP2350 is a more complex Cortex-M33 core, a large (and a bit sideways) superset of the simple M0+.My first language was 6502 machine code (pencil and paper then hex on keypad, no assembler!), and I admit I had lots of fun.Would I do that now with availability of cheap powerful HW, excellent free compilers and IDEs? Well, I might but just for the nostalgia value...EtA: Oh, and if you come from PIC or 8051, the simple memory model and availability of registers are a breath of fresh air!

author: eleguy
author_rank: Regular Contributor
timestamp: March 07, 2025, 09:44:26 am
content: I would add ESP32 to the list. Lots of speed and memory. Depends surely in which amounts one is going to buy MCUs but there is no really difference between "10 cent" and "dollar" thingies in smaller amounts. Shipping costs are anyhow way higher. Availability, easiness, adoption rate, documentation, ... there are many other things that do weight much more.

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2025, 10:03:11 am
content: Quote from: newbrain on March 07, 2025, 09:35:14 amStill far more complex than RV32I (or RV32E, the 16 register variant that competes with Cortex-M0), for little or no benefit. There are a lot of different specialised instruction formats each with arbitrary limitation, and use of the upper eight registers (five other than PC, LR, SP) is quite limited: only MOV, ADD, and CMP.QuoteNot quite correct. The CPU stacks the registers that the C compiler won't. If you're writing in asm then you still have to remember to push and pop R4-R11 if you use them.QuoteNot correct. All instructions are 16 bit except `bl`, fences, and CSR read/write.Literal operands are not stored in the next 16 bits of code, but are accessed with a PC-relative load, usually from a constant pool just after the end of the function (sometimes after an unconditional branch in a very large function).QuoteMine too, but out of necessity. I still do a bit of 6502 for fun, but ABSOLUTELY would not recommend any 1970s 8 bit CPU except the M6809 for beginners. But AVR, Arm, or RISC-V just make so much more sense today.AVR is annoying for handling values larger than 8 bits, especially including pointers.All the various Arm instruction sets are annoyingly complex: A32 you have to deal with predication, T16 has too many instruction formats each with weird non-orthogonal limitations, T32 and A64 are too big.RV32I or RV32E are the simplest and most orthogonal, with no special cases. If your CPU has the C extension the assembler will just transparently use that to reduce code size when it can with no thought on your part, or you can disable the assembler using it to get nice uniform 4-byte instructions.

author: Psi
author_rank: Super Contributor
timestamp: March 07, 2025, 10:06:38 am
content: Seriously consider your reasoning for wanting to program in assembler.It just makes things complicated for no reason, unless you simply want to learn assembly or need to extract every last clock cycle/flash space from an existing mcu project. If you do want to use ASM 32bit mcus will require less coding, since you can work with large numbers directly. But be warned, really older cpus were designed for humans to code them in asm, where as modern cpus are designed with compilers in mind so things are not always as simple for a human.There's no need for a programmer with ZIF socket, you can program modern chips while they're in circuit which is much easier and faster.If you need a USB connection on the MCU you'll probably want something 32bit, like STM32. For most 8bit mcu's you use an external usb to serial chip to avoid having to work with USB directly. Also USB requires a clock that's faster than most 8bit mcu's have.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 07, 2025, 10:11:46 am
content: ARM is one of the nicest architectures to program in assembler, but unless you're specifically doing it as a learning thing there's little need nowadays, though at least a general undertanding of what a compiler is doing can be very valuable.

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2025, 10:25:28 am
content: Quote from: Psi on March 07, 2025, 10:06:38 amThat is true, but in the sense that they are almost impossible to write a good compiler (with efficient code) for, but merely very difficult for humans to program because humans are able to understand what properties something like C has to guarantee that are not actually needed in a particular situation, and also to modify their algorithm to fit the limitations of the CPU.QuoteThe first part is true, the second is false. Everything that makes a CPU easy for a compiler also makes it easy for a human.Historically there were some things that were done that were not especially easy for a compiler, but mechanical bookkeeping could cope with, but that were taxing for a human to keep track of. Those are mostly:- branch delay slots (in MIPS, SPARC, PA-RISC, i860, M88k, Am29k, SuperH)- no pipeline interlocks in early MIPS, which meant you had to make sure there were sufficient other instructions between instructions A and B if B used the result of A, otherwise you got the old value of the register not the new one.That stuff is all long gone.The only thing that remains is that in CISC you can write complex addressing modes with many operations in one line of code such as multiple adds, scaling one of the operands, and one or sometimes more loads from memory. In RISC you have to instead write several simple instructions in a row using one or more temporary registers. This is not a problem since you usually have a lot of registers.

author: newbrain
author_rank: Super Contributor
timestamp: March 07, 2025, 11:06:10 am
content: Quote from: brucehoult on March 07, 2025, 10:03:11 amYup, you are obviously right on both counts.I was really sloppy, and linked to the documentation to make up for it, not intending this to be a course in Arm assembly.I should have cared more, since I knew what you remarked (especially about the Thumb2 IS).QuoteEh, I would have loved to get my teenage hands on one*, but I have one now, and sooner or later I'll make a FORTH system out of it - single instruction inner interpreter FTW!QuoteI have nothing against RISC-V, and I can see its advantages, but for the first foray into 32 bit territory I still think a bit more mainstream is an easier path.The regularity of the IS is a plus though, I have some RISC-V dev boards, but nothing with the support level of the Pico, are there any that you can suggest?*Among many other things, not all CPU related...

author: JPortici
author_rank: Super Contributor
timestamp: March 07, 2025, 11:21:47 am
content: Quote from: Analog Kid on March 07, 2025, 02:59:31 amI would say PIC24FJ512GU410 series:https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/DataSheets/PIC24FJ512GU410-Family-Data-Sheet-DS30010203D.pdfIt's my goto for these requirements(but doing it all in assembly, nah.)

author: brucehoult
author_rank: Super Contributor
timestamp: March 07, 2025, 12:59:17 pm
content: Quote from: newbrain on March 07, 2025, 11:06:10 amThe Pico 2 is the obvious example if you like the Pico. You get all the same Pico documentation, same peripherals, same everything but with the possibility to write your code using RISC-V instead of Arm. You can even run one Arm core and one RISC-V core at the same time if you really want to.The CH32V003 is a cool little simple cheap chip, with only a fraction of a features of the Pico, but perhaps as a result something you're more likely to be able to completely understand. THE Olimex RVPC is a cool little €1 kit using a CH32V003 in the 8 pin package as the only active component  but manages to provide a PS/2 keyboard input, a bit-banged VGA output, and sound. The chip comes preprogrammed with a reimplementation of the Apple I's WozMon which lets you examine memory, poke new values in, and run code starting as an arbitrary location. RV32E isn't as easy to hand-assemble code for as the 6502 was, but on the other hand most people now will have a PC handy to do that on, and then only have to type the hex codes in.There are also some other demo programs e.g.2k of RAM and 8 pins, baby!The bare CH32V003 chip is also quite fun, in the same way as an ATtiny85, in that it can run on anything from 2.8V to 5.5V and once programmed doesn't need any external components such as crystal or capacitor, but just the power supply. So it's very easy to use on a breadboard (with an SOIC-8 breakout board), or dead-bug, or things like that. ok, there's a transistor to drive the piezo speaker

author: Peabody
author_rank: Super Contributor
timestamp: March 07, 2025, 03:40:37 pm
content: I did a lot of assembly coding for the 6502 back in the day, but did some more recently with TI's MSP430 line. They are 16-bit von Newmann processors, so assembly was pretty straightforward, and very similar to 6502. They have internal oscillators, and use very little power. TI's IDE however was more than I wanted to learn to use, so I just used a programmer's editor and the Naken assembler, which is free, tiny and fast. Flashing was JTAG using TI's Launchpad, or in-circuit, using TI software.But the big advantage of the likes of Arduinos and ESP32 is the abundance of "modules" from the Far East to do almost anything you would want on the hardware side. Nothing like that exists for the MSP430. And the software catalog for those lines is immense, just in case you ever want to go to higher level programming. I just don't know what assembly is like for those chips.Anyway, I think there's something to be said for using what everybody else is using, which tends to make things easier and cheaper.

author: zapta
author_rank: Super Contributor
timestamp: March 07, 2025, 05:35:54 pm
content: If you want to program in assembler, I would stay away from 32 bit architectures, because of their complexity (not necessarily the instruction set itself but the peripherals, configuration, and so on), and go with 8 bit MCUs. Also, I would also look for a hardware debugger or at least a simulator that support breakpoints and single stepping.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 08:12:47 pm
content: Let me just clear up one point here, which is my choice of programming language:Yes, I prefer to use assembler rather than C/C++/Python, etc.It's not because of any raging "need for speed", although that is often the outcome;it's just that I prefer using assembly language over a HLL. I've been doing it for a long time on x86 under Windows.And my previous experience with a micro was programming the SX-28 in assembler, which worked nicely.I'm a hobbyist, not looking to ever go into production with any of my li'l projects.It appears from several responses that I'll be able to program most any micro in its native assembler, which is good.

author: bobxyz
author_rank: Contributor
timestamp: March 07, 2025, 08:32:18 pm
content: I'd suggest buying a Raspberry Pi Pico board for $4 (https://www.sparkfun.com/raspberry-pi-pico.html) and trying it out with MicroPython (https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-python-sdk.pdf). There are lots of good introductory tutorials, and a couple books, easily available. See if you like the environment and the documentation. If not, try a simple STM32 board, or post back here with what you liked and didn't like.While there's a satisfaction in programming in Assembly and getting down-and-dirty with the CPU architecture, the days of needing to use Assembly are long gone. Back in the day, memory was expensive and lower cost processors didn't have enough to easily support a C stack, nor were they fast enough to overcome inefficient C compilers and/or poorly written code. Today, even the $4 pi pico board has 256KB of RAM and 2MB of flash, with dual Arm processors, and an Arm processor architecture that works well with compilers.If you like playing at the hardware level, the RP2040 includes a couple PIO modules that are programmed in assembly using a tiny instruction set. Quoting the manual:Quote

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 08:39:13 pm
content: Quote from: bobxyz on March 07, 2025, 08:32:18 pmYou're not getting what I'm writing.I don'tneedto use assembly language:Ipreferto use it.So Python? Thanks but no thanks.

author: peter-h
author_rank: Super Contributor
timestamp: March 07, 2025, 08:57:25 pm
content: I did megabytes of code in asm too, Z80 etc. Then went to C. Much more productive...Basically, most micros can do most jobs. You can make choices on various criteria. Some people hate STM. I use STM but made progress only because somebody else set the project up (Cube IDE). But from where I am now, I will carry on and the 32F4 will do me for the rest of my life (~20 years left). I would not use Atmel AVR because of poor product life. Various things like that from different people. I would not use a chinese chip (ESP32) because of the obvious political risk. I have a lot of experience of doing business with China...Now what can really drive a chip decision are things like- low power (note: you can make any chip low power if you are able to run it on a small duty cycle)- special peripherals- previous experience (can be hugely significant if you own the business)So think about that.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 07, 2025, 09:09:19 pm
content: Can we stick to common lexicon:QuotePlease excuse the pedagogy.

author: Tation
author_rank: Regular Contributor
timestamp: March 07, 2025, 09:24:16 pm
content: Quote from: brucehoult on March 07, 2025, 12:59:17 pmI'm not, in fact, a heavy supporter of the RP MCU's, but from the OP goals, I think that Pico 2 boards are the ones best fitting his needs.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 07, 2025, 11:58:53 pm
content: Quote from: jpanhalt on March 07, 2025, 09:09:19 pmYou're absolutely correct here, and your pedantry is excused.

author: bobxyz
author_rank: Contributor
timestamp: March 08, 2025, 12:04:06 am
content: Quote from: Analog Kid on March 07, 2025, 08:39:13 pmOK, since you're set on using assembly language, why don't you try a simple search on youtube to see if you can find what you're looking for? For instance:https://www.youtube.com/results?search_query=arm+assembly+languageorhttps://www.youtube.com/results?search_query=rp2040+assembly+language

author: Analog Kid
author_rank: Super Contributor
timestamp: March 08, 2025, 12:06:45 am
content: Because I don't use YouTube for obtaining that kind of information. I prefer text.So far you're 0 for 2.

author: squadchannel
author_rank: Frequent Contributor
timestamp: March 08, 2025, 12:08:03 am
content: I would recommend tinyAVR and megaAVR series. They are inexpensive with a reasonable pin counts, and development boards (Curiosity nano, Explained nano etc...) can be purchased at low cost.I think ASM can be used as well. But I never used ASM.

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 12:21:14 am
content: Quote from: squadchannel on March 08, 2025, 12:08:03 amBlind leading the blind.Yes, OF COURSE asm can be used on EVERY microcontroller.The issue is that some ISAs make it very difficult to write a compiler that can produce small and fast code, and so you HAVE to use asm -- or suffer inefficiency.Back in the old days we used to implement small virtual machine in asm that presented a better compiler target, and then had a Pascal or C etc compiler emit some more or less nice (and compact) bytecode or threaded code for most of the program, and then write the speed critical parts in asm.Tokenised BASIC and Python are the same idea, but even less efficient.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 08, 2025, 12:45:33 am
content: Quote from: brucehoult on March 08, 2025, 12:21:14 amOK, I totally believe you on that.However, question: are all the assembly languages used by microcontrollers pretty well documented? That would be one of my requirements if it's an asm that I don't already know. (Basic reference manual.)So I'm going to ask for a little hand-holding help here if y'all don't mind:I went to Microchip's web site to search for μprocessors. However, it's difficult to do so, since there's so much stuff there.So if some of y'all would be so kind as to point me to specific μprocessorsandthe required programmer for that chip, say on Amazon or some other vendor, I would really appreciate. Just some links to get me started.Another preference of mine would be for through-hold chips, if that's possible. If not, so long as the chip can be gotten on some kind of breakout board, that would be OK.Thanks in advance.

author: squadchannel
author_rank: Frequent Contributor
timestamp: March 08, 2025, 12:56:07 am
content: Quote from: Analog Kid on March 08, 2025, 12:45:33 amCuriosity nano and Xplained, the board has a debugger. you only need to connect it to USB and develop with Microchip (Atmel) Studio.https://www.microchip.com/en-us/development-tools-tools-and-software/development-tools-category-explorer?category=curiosityboards&subcategory=8-bit-curiosity-nano-boardshttps://www.microchip.com/en-us/development-tools-tools-and-software/development-tools-category-explorer?category=xplainedboards&subcategory=xplainedI recommend tinyAVR/megaAVR series. comparison chart is included.https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ApplicationNotes/ApplicationNotes/Getting-Started-with-GPIO-DS90003229B.pdfNot much difference between the different series - have a DAC, how many timers, pins etc.There are very few modern MCUs with DIPs; for the AVR, I believe the ATmega4809 has a DIP.tinyAVR, there are 8-pin, 14-pin, and 20-pin SOIC packages. QFPs are common.The nice thing about new AVR series is that it hasLUTs(CCL, Configurable Custom Logic), although there are not many. This is useful when you want to build a bit of logic.also, as others have said, I would suggest programming in C.

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 01:11:47 am
content: Quote from: Analog Kid on March 08, 2025, 12:45:33 amhttps://www.aliexpress.us/item/1005004895791296.htmlThe $8 "Kit 1" will be fine.See Dave's video I pointed to above for a slightly fumbling quick start.Instruction set reference:https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view?usp=drive_linkYou only need to read the Introduction, RV32I, RV32E, and Zicsr sections.Also:https://drive.google.com/file/d/1Ja_Tpp_5Me583CGVD-BIZMlgGBnlKU4R/view?usp=drive_linkThere are a lot of good examples at...https://github.com/cnlohr/ch32fun

author: westfw
author_rank: Super Contributor
timestamp: March 08, 2025, 01:11:59 am
content: QuoteThe AVRs and TI's MSP430 series are both pretty nice to program in assembly language.But the "most recent" AVRs you should be looking at are the AVRmmmFFpp families that have come out since the microchip acquisition. (mmm is memory size. FF is "family", DA, DB, DD, DU, EA, EB, and pp indicates the pin count. I haven't quite figured out the "family" names, but roughly the Dx families are ATmega equivalents, the Ex are ATtiny equivalents, and the DU has native USB. An AVR64DA28 (64k program memory, 8k RAM, 28pin SOIC or SSOP) will set you back about $1.50, in ones, from Digikey. (DIP somewhat more expensive.))Note that direct USB support in 8bit chips is pretty rare. But program/debug had become easier and cheaper than it used to be. (The above families all use UPDI, which can be implemented with USB/Serial converter and a diode.)I'm going to disagree with all the people claiming that "you can program any chip in assembly" and "ARM assembly is nice."The fact is that modern 32bit architectures do a really poor job of documenting their assembly languages - datasheet examples are all in C, books and tutorials use C, the development environments provide peripheral definitions in C, etc.While the ARM32 instruction set isn't so bad, most of the low-end microcontrollers will be M0 or M0+ that implement the V6m architecture, which is a rather ugly thumb subset of the full ARM (ugly particularly WRT the size and availability of immediate operands.) (M3 and M4 are considerably better.)RISC-V would start out my figuring out exactly which "extensions" your particular chip implements, and which it doesn't, and having to remember that each time you refer to the instruction set references (published by the RISC-V folks, not the chip vendors. So you won't get nice "instruction set summary" pages in your datasheet or chip reference manual.ESP... another "extensible" architecture. I don't know whether the chips actually implement any extensions. Good luck even tracking down the assembly language docs. (Hmm. I guess they do actually exist, from Espressif, without having to go all the way back to the Cadence Tensilica docs.)And then there's converting the header files for the (complex) peripherals. Because they're probably full of "struct" and "enum" stuff that won't parse in the assembler. There was a discussion quite a while ago now about putting together a minimal assembly language environment for STM32F103. Outcome (and pointers to the discussion) here:https://github.com/WestfW/Minimal-ARMAnd mostly: there's no significant "user community" for assembly language on ESP, ARM Cortex M, or RISC-V. Unlike AVR or i86. :-( You can't pop up a question "why doesn't this instruction sequence work like I think it should; is there a better way?" without getting mostly silence and/or "Why don't you just use C?" as reply.

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 01:19:44 am
content: Quote from: westfw on March 08, 2025, 01:11:59 amAgreed on that.QuoteA beginner has no need to go past RV32I (or the 16 register RV32E for the CH32V003) for a very long time. All documented together in one chapter.QuoteESP is a brand of Espressif, not an instruction set. Older ESPs used a couple of different Xtensa ISAs, newer ones (and all future ones they say) are RISC-V. ESP32-C3, ESP32-C6 etc.QuoteThere are plenty of people right here who can and do answer any such questions, on pretty much any ISA, as well as other places such as Reddit /r/riscv, /r/asm etc

author: Analog Kid
author_rank: Super Contributor
timestamp: March 08, 2025, 02:06:08 am
content: Quote from: brucehoult on March 08, 2025, 01:11:47 amWell, I opened up that RISC-V PDF. Sorry, don't like the look of RISC programming at all. Too much for what I had in mind.I think something more 8080-like would suit me better.Thanks anyway.

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 02:20:19 am
content: Quote from: Analog Kid on March 08, 2025, 02:06:08 amWow. You're going to hate Arm or MSP430 or AVR just as much then.Things like 8080 are long gone for very good reason -- they're awful.Maybe 8051 is for you. There are lot of them still available, but they're very much legacy devices.Here you go:https://www.adafruit.com/product/5960

author: bobxyz
author_rank: Contributor
timestamp: March 08, 2025, 04:59:14 am
content: Quote from: Analog Kid on March 08, 2025, 12:06:45 amOh, ok, you're in thedinosaurold-school class.Based on your questions, you're out of touch on what's easily available today. Please ask your grand kids, or the neighborhood kids, what they're learning in their middle school STEM classes. Go spend 20 bucks and buy a couple of their learning boards. Go through the basic blink a LED tutorials for each. Then, change the code to blink a morse SOS code. Once you've actually done something, instead of just ......., feel free to ask better questions about vintage computing using assembly language.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 08, 2025, 08:06:33 am
content: Quote from: Analog Kid on March 08, 2025, 12:45:33 amThe ATmega range of MCU's might fit you best. The assembly language may be less easy than 8080, but not that hard to learn. They also have through hole versions.Here are some links to the documentation:https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdfhttps://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdfhttps://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdfSee this vendor on Aliexpress. It has several versions of the Arduino UNO, that make use of the ATmega MCU's:https://www.aliexpress.com/item/1005002997846504.htmlTo program these without the Arduino IDE and the bootloader it likes, an USBASP is needed:https://www.aliexpress.com/item/1005006759871321.htmlProgramming can be done with avrdude:https://www.nongnu.org/avrdude/user-manual/avrdude.html#IntroductionThe assembler to use can be AVRASM2 or the GNU avr-gcc suite and most likely others can be found.http://www.rjhcoding.com/avr-asm-assemblers.phphttps://gcc.gnu.org/wiki/avr-gccThe GNU avr-gcc suite does it all. Assembly language, C and C++;Well that is it for the AVR based MCU's.If you are interested in ARM based MCU's, check out the documentation site on that. It ain't easy to find what you need due to the large amount of different version of cores they have.https://developer.arm.com/documentationI have to say you must be a die hard assembly programmer, to also do it on X86 under Windows. Some of the comments I have read here are about the peripherals and the examples in the documentation being based on C, and that C makes life easier, well that is partially true. Setting up the peripherals is not going to be any harder in assembly compared to in C. It is just memory addresses where you write configuration data to get it working in the way you need it. The peripherals in the more "modern" MCU's tend to be a bit more complex, and you need to study the manuals thoroughly to get how they work. That is, if there is good documentation to be found. That is not the case for some of the MCU's out there.To each it's own I say, but I would still like to encourage you to look into C. It will make programming easier and the code is more reusable between different MCU's. C code that you write for an AVR based core can reused on an ARM based core, as long as it is not targeting peripherals of course. That can't be said for assembly language. Probably not a big selling point for a hobbyist like you, who is just looking for something new to play with.That you "spit" on python I can fully understand. I don't like it either.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 08, 2025, 08:10:09 am
content: Quote from: Analog Kid on March 08, 2025, 12:45:33 amIf you want simple assembler and DIP, that points to the 8051 families or AVR8051 with english docs and debuggers:https://www.silabs.com/mcu/8-bit-microcontrollershttps://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/https://www.abov.co.kr/en/products/product_overview.php?category=8bit_mcuQuote from: Analog Kid on March 08, 2025, 12:45:33 amDIP is certainly less common. Atmel/Microchip still have some DIP 8051, or these from STC, with many assembler examples included, You need an AI doc translator.https://www.stcai.com/xpscand well stocked many DIPs - 48 hits from DIP8 to DIP40https://www.lcsc.com/brand-detail/151.htmlThese have UART (and some have USB bootloaders, just connect to USB and P3.2=L), so are easy to download/run.The STC8H8K64U comes in DIP40 and DIP28 and modules, and the newer STC8051U/Ai8051U has more RAM and classic pinouts.PCB'shttps://www.aliexpress.com/item/1005005144706171.htmlhttps://www.aliexpress.com/i/1005003688412658.htmlhttps://www.aliexpress.com/item/1005006439568251.htmlhttps://www.aliexpress.com/item/1005008064635231.html

author: Tation
author_rank: Regular Contributor
timestamp: March 08, 2025, 08:33:24 am
content: Quote from: Analog Kid on March 08, 2025, 02:06:08 amThe Risc-V Reference Cardhttps://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdfexposes the Risc-V assembly in just two pages. Me myself have made a similar doc for Cortex-M0 assembly, including many assembler directives, in three pages. There are in deep documents directly from risc.org and Arm in case of doubt. Both ISAs are WAY more orthogonal, simple and user friendly than any 80xx one. I guess that, if you do not "like" any of Risc-V or Arm ISAs, then you will not like any other.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 08, 2025, 09:00:48 am
content: Quote from: Analog Kid on March 07, 2025, 02:59:31 amZIF limits to not many...Not sure which pinouts this supports - I think STC8H8K64U, and it seems some smaller DIP packages too?STC/USB-Writer1A - also has an ISP header out the side (for STC8051U etc UART pgm).https://www.aliexpress.com/item/1005008202602411.htmlSome info herehttps://www.stcaimcu.com/forum.php?mod=viewthread&tid=11205https://www.stcmicro.com/pdf/stc-tool-en.pdfThis is ZIF with STC8H8K64U DIP pinouthttps://www.aliexpress.com/item/1005006439568251.htmlOR standard legacy pinout ZIF only, needs ISP board - should work with STC8051Uhttps://www.aliexpress.com/item/1005004544800641.html

author: rteodor
author_rank: Frequent Contributor
timestamp: March 08, 2025, 09:16:39 am
content: Quote from: Analog Kid on March 08, 2025, 02:06:08 amI do not have any answer fo you, just asking: do you feel that a CISC arch might be more suitable for you ? I could see why an ASM programmer would be more efficient with CISC - less chanches of error and more efficient at writting code.Do you prefer a MCU that does OoO (out-of order) execution or do you prefer to take care of the sequencing by yourself to get best performance ?All in all, do you prefer that the hardware do things for you or you want to master it yourself ?Also, why ZIF ? It sounds expensive. Modern/mainstream in-circuit flashers&debuggers can cost almost as a coffe in town.

author: djsb
author_rank: Super Contributor
timestamp: March 08, 2025, 09:55:47 am
content: Part 1 of PIC assembly language tutorial (PIC16F) by John Becker.https://www.worldradiohistory.com/UK/Practical-Electronics/00s/Everyday-Practical-Electronics-2003-04.pdfand here is part 2https://www.worldradiohistory.com/UK/Practical-Electronics/00s/Everyday-Practical-Electronics-2003-05.pdfand part 3https://www.worldradiohistory.com/UK/Practical-Electronics/00s/Everyday-Practical-Electronics-2003-06.pdfI found these very useful when learning the basics of PIC assembly in 2010. I use C (CCS C) now. PIC's are useful because they havemany devices in DIP through hole packages. We use PIC16F819,PIC16F1847 (all 18 pin DIP) in our current embedded systems class. We are incorporating ESP32 for future use. I personally like the PI PICO, and it seems to be VERY popular. I would NOT attempt to try to understand the PICO ARM ISA unless forced by necessity.

author: westfw
author_rank: Super Contributor
timestamp: March 08, 2025, 10:03:46 am
content: QuoteI seem to recall being shocked that some “expected” instructions didn’t show up till the “bit manipulation extension(s)” - the rotates, perhaps?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: March 08, 2025, 10:03:52 am
content: If you want a variety of parts in DIP then Microchip wins hands down - everything from an 8 bit PIC8 in DIP8 to 50MHz PIC32 with 64K Ram and 256K flash in DIP28 (also SO,SSO ,QFN & QFP). And the same IDE and programming hardware for all of them.

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 10:15:40 am
content: Quote from: westfw on March 08, 2025, 10:03:46 amThere are an infinite number of instructions that you could add to an ISA. That's how they get complex and hard to learn. Just because something like rotates or a carry flag were common in 1970s ISAs doesn't mean they should be automatically included today. It needs to be demonstrated that they provide sufficient benefit to the system as a whole, not just save a few cycles on a specific micro-benchmark.Rotates are seldom needed and not performance-critical in most code and can be very easily implemented in software as(x << n) | (x >> -n)which, given single-cycle shifts, is going to be just two to four clock cycles and a lot faster than the bit by bit rotates on many older CPUs.Rotates are not in either the base RV32I instruction set or the B extension, but were added in the "Zbkb: Bit-manipulation for Cryptography" extension which does heavily use them.

author: squadchannel
author_rank: Frequent Contributor
timestamp: March 08, 2025, 10:27:32 am
content: Quote from: mikeselectricstuff on March 08, 2025, 10:03:52 amyep, Microchip (Atmel) has a product line that encompasses even this niche market.Chinese MCUs are cheaper, but I think they are inferior in terms of availability, software, and whether or not they have a community. I don't even know how long those MCU manufacturers will be around.may be good for mass production.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 08, 2025, 01:12:24 pm
content: @mikeselectricstuffPic8? I think you may mean the PIC10Fxxx, but they don't have a lot of pins. The 12F series, e.g., 12F683 and 12F1840 have a lot of peripherals but are also limited in pins.* They generally have only 8 pins, which allows 5I/O's and one I only. I believe they have now been integrated into the code/instruction identical 16F family with 14-bit core, and more pins/ports. That allows a page size of 2048, e.g., page 1 starts at 0x800. The 18F are 16-bit core, 8-bit devices. The have even larger page sizes, more instructions, and enhanced hardware math.That entire group is pretty much designed for Assembly (MPASM or AS with MIcrochip's newer assemblers). I was going to mention those lowly PIC's, but was embarrassed to do so considering the instruction sets available for other devices mentioned so far. Nevertheless, with just 49 instructions in the 16F series and all the hardware capabilities, you can do a lot with them.*I would ignore the 12F5xx devices that are 12-bit core, only 33 instructions, and no interrupts. The 12F6xx have 35 instructions and interrupts, but I see no reason not to go to the 14-bit core devices (12F1xxx and 16F1xxx and later) with 49 instructions and even more peripherals.

author: Peabody
author_rank: Super Contributor
timestamp: March 08, 2025, 03:11:17 pm
content: I don't have experience with either, but wasn't the SX family that you already know intended as a PIC replacement? I just wonder if you might be most at home with PIC.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 08, 2025, 07:25:54 pm
content: Quote from: Analog Kid on March 07, 2025, 02:59:31 amThis recent news applies to Microchip parts. For a HS-USB link, this is quite a good price, You can wire this to a ZIF of your choice.https://edacafe.com/nbc/articles/1/2122692/Microchip-Technology-Releases-Versatile-MPLAB-PICkit-Basic-DebuggerMPLAB® PICkit™ Basic In-Circuit Debugger USD/unit: $29.99Broad CompatibilitySupports PIC® and AVR® MCUs, dsPIC® DSCs and SAM Arm® Cortex®-M based MCUs and MPUsSimple ConnectivityUSB Type-C® interface for easy PC connectionHigh-speed USB 2.0 interface with up to 480 Mbps data transferI did not see a device list, but this looks comprehensive list of interfaces. SPI should go back a long way.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 08, 2025, 08:49:12 pm
content: Welll, at this point, given the still-overwhelming array of choices facing me, I'm not sure what to say.Part of me is thinking to just go ahead and buy one of those inexpen$ive μcs w/programmer and give it a spin; not much to lose but a bit of time spent learning a new assembly language.I'll let go of my ZIF requirement, which assumes through-hole parts: as I wrote earlier, if I end up with a surface-mount part that'll be OK so long as it comes on a breakout board. I don't deal with any SMT parts myself.I still tend towards the simpler, CISC, 80xx-like variety of μcs, like the SX-28 I used earlier (yes, I think it was sold as a PIC replacement). Rotates? probably don't need 'em. Don't need anything fancy like out-of-order execution, fancy caching, etc. Not about to build any speed-intensive devices here just yet.If anyone cares to post links at this point, what I'd really prefer would be links to purchasable items on Amazon/Ali/electronics vendors sites, etc., rather than any Microchip or equivalent pages; I'd like to see what packages I can actually buy, how much they are and what they contain. Again, minimal needs here: μc, programmer and just enough software to upload code from Windows 7. A debugger would be icing on the cake.

author: temperance
author_rank: Super Contributor
timestamp: March 08, 2025, 10:43:00 pm
content: Any ARM based controller will require quite a bit of code just to set an IO port H or L in assembly language. The reference manual for a simple ARM cortex controller is easily over 1K pages.STM32F031 ref manual:https://www.st.com/resource/en/reference_manual/rm0091-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf-After the ARM core is setup by means of start up code in assembly or C and before any work can begin, you must setup the clock tree: page 99-Complex interrupt controller-DMA-Complex GPIO: many things must be configured before you can do anything with them. Timers, ADC's, UART, SPI, I2C,... The complexity allows for more advanced things. Take a look at timer TIM1 at page 329 to get an idea. But you get a lot of timers in comparison to a simple 8 bit controller.ATMEGA48 ref manual:https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7530-Automotive-Microcontrollers-ATmega48-ATmega88-ATmega168_Datasheet.pdf-Simple to get going-Simple interrupt controller-Easy to use peripherals-No DMA (as far as I know only the xMega has a DMA controller)For simple things programmed in assembly my choice would be an 8 bit controller.You asked for what's available:Debugger:https://www.microchip.com/en-us/development-tool/atatmel-iceThat together with an Arduino and microchip studio would work fine.

author: Smokey
author_rank: Super Contributor
timestamp: March 08, 2025, 10:58:10 pm
content: Quote from: Analog Kid on March 08, 2025, 08:49:12 pm... so you want to start a major open ended learning adventure with a new microcontroller (in the most difficult way possible using assembly) and presumably some actual projects in mind but you aren't even willing to put in the work to google where to buy the stuff people have been recommending to you?If someone sends you a link of a thing to buy, are you going to ask they come to your house and set it up for you too?

author: beginner_max
author_rank: Newbie
timestamp: March 08, 2025, 11:04:25 pm
content: Use STM32F103 bluepill, this is enough for the most and you can use any bigger later without new learning.Use Mkiroe then you can use Basic, Pascal or C with the same GUII bought all old ones for avr and ARM Pascal and CThis is the easiest start and you can do all with that and you have a better GUI/RAD with many Units/Libs at ones with manuals and other look at mikroe.com, they have own boards too

author: temperance
author_rank: Super Contributor
timestamp: March 08, 2025, 11:09:46 pm
content: Quote from: beginner_max on March 08, 2025, 11:04:25 pmFrom the original question:Quote

author: brucehoult
author_rank: Super Contributor
timestamp: March 08, 2025, 11:10:53 pm
content: Quote from: Smokey on March 08, 2025, 10:58:10 pmI've already given purchase links for both RISC-V and 8051 boards, with USB programming, as OP is asking for. Others have given other such links.We've got ourselves either a 'tard or a troll.

author: Smokey
author_rank: Super Contributor
timestamp: March 08, 2025, 11:20:12 pm
content: Quote from: brucehoult on March 08, 2025, 11:10:53 pmget yourself ready for an onsite dayHe's probably going to make you pay your own travel expenses, and buy lunch!

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 08, 2025, 11:25:22 pm
content: Quote from: Analog Kid on March 08, 2025, 08:49:12 pmI dug some more into that STC USB-Writer1A US$21.50 on Aliexpress = ZIF + ISP connectorhttps://www.aliexpress.com/item/1005008202602411.htmlSoftware :https://www.stcai.com/gjrjhas English option.That ZIF STC USB-Writer1A is relatively new, but looking in the 2025 device data sheets, it seems to have DIPxx support in the ZIF for pretty much all their new/active families of STC8G, STC8H, STC12H, Aixx, added ~Dec 2024.That covers most of the modern lcsc STC MCU DIP parts.https://www.lcsc.com/products/Microcontrollers-MCU-MPU-SOC_11329.html?brand=151STC8051U-34K64-PDIP40STC8H8K64U-45I-PDIP40STC8H8K64U-45I-SKDIP28STC12H1K28-36I-SKDIP28STC12H1K28-36I-DIP20 << this one has AT89LP2052/4052(2051) pinout*, but adds 10b ADC & 1.19V 1% VREF, and faster core, more RAM/Flash, 24MHz/32k Xtal Osc and RTC, PCA, PWM...STC8G1K08-38I-DIP20STC8G1K17-38I-DIP16STC8G1K17A-36I-DIP8I think STC's crystal based MCU writers can auto-trim the RCOSC at program time, (eg after reflow) it then specs to 0.3% at 25'C and -0.88%~+1.05% -20~+65- not as good as a crystal, but good for MCU RCOSC.The 20pin and above parts have crystal pins.The same vendor has small QFN modules, of the DIP/castellated edges style.https://www.aliexpress.com/item/1005008064635231.htmlSTC8H8K64U-QFN32 Breakout US$2.11STC8H8K64U-QFN48 Breakout US$2.99* There are many 89C2051 modules/project boards out there.egStepper motor DIP20 2051 pinout, with Crystal US$3.50https://www.aliexpress.com/item/32839536291.htmlStepper + IR receiver + remote + 7Seg DIP20 2051 pinout, with Crystal US$4.61https://www.aliexpress.com/item/4000011315703.html& many 4 & 6 digit LED clocks.Addit2: And discussion of a LCR Meter kit using the STC89C51RD (which would upgrade to much newer STC8051U, if desired)https://www.elektormagazine.com/articles/reverse-project-02-enhancing-an-lc-meter-kitAddit : one of these 78c ZIF adaptors for SO8Nhttps://www.aliexpress.com/item/1005006529687107.htmlallows you to prototype and program the STC8H2K12U-45I-SOP8 25c/100+, supports 144MHz PWM and 12b ADC

author: Analog Kid
author_rank: Super Contributor
timestamp: March 09, 2025, 12:10:00 am
content: Quote from: Smokey on March 08, 2025, 10:58:10 pmOh, c'mon, give me a fucking break.It's just as easy for anyone responding to post a link to a purchasable item as it is to post a link to, say, something on Microchip's site which would then require more digging on my part, which to be honest I would like to avoid if at all possible. (Yes, I admit it: I'm lazy to that extent. So sue me.)So it's just as easy for them and easier for me. What's wrong with that?And no, no further hand-holding required. And to whoever posted that I'm making things harder for myself by using assembly language, no, because as I said that's my preference, been programming in asm for decades now.

author: squadchannel
author_rank: Frequent Contributor
timestamp: March 09, 2025, 12:27:44 am
content: ATtiny3217 Curiosity nanohttps://www.digikey.com/en/products/detail/microchip-technology/EV50J96A/11618271?s=N4IgTCBcDaIKIDcCsAGAVgTgGwgLoF8gIf you want more features, buy something else.

author: brucehoult
author_rank: Super Contributor
timestamp: March 09, 2025, 12:41:39 am
content: Quote from: Analog Kid on March 09, 2025, 12:10:00 amI have done exactly that, multiple times, for boards with different ISAs.

author: rsjsouza
author_rank: Super Contributor
timestamp: March 09, 2025, 12:44:22 am
content: I tend to have a soft spot for MSP430 and its inexpensive set of tools. Its assembly is very sweet to program (IMO).They have various assembly examples and simple projects available around. A few of them are shown below.https://www.ti.com/tool/MSP430-FUNCTION-CODE-EXAMPLES

author: Analog Kid
author_rank: Super Contributor
timestamp: March 09, 2025, 12:49:58 am
content: Quote from: brucehoult on March 09, 2025, 12:41:39 amOK, Bruce, I totally believe you.Tell you what: when I get some time I'll go back through the now more than 70 replies in this thread and see what you posted. To be honest I have not followed every single link that every poster posted because you know what? I actually have other things to do. Unbelievable, huh?

author: forrestc
author_rank: Unknown
timestamp: March 09, 2025, 01:13:10 am
content: Personally, I'd go one of two ways:1. Get a PIC18F26Q24 or a PIC18F46Q24. These are available in 28 and 40 pin DIP packages. Buy a MPLAB SNAP in circuit debugger-programmer. Total investment, about $20. This part is a direct descendent of earlier parts that were very popular in the DIY world such as the PIC18F26K20 so many examples should just work. Note that you just program in-circuit - you run 5 wires from the programmer to your circuit (VCC, GND, Reset & 2 progamming pins) and it takes care of the rest. The PIC core was specifically designed for human programmers - which is why it isn't all that great with C. There is some argument to go with a PIC16F part instead as they have an even simpler assembly language (35 instructions total to learn vs 77 on the PIC18) but I tend to lean toward the PIC18 line just because it tends to have a bit more powerful core and more memory.2. Do the same but use one of the Arduino UNO boards which has a AVR processor on it. I understand that the SNAP programmer can program these directly. I don't have a lot of experience with AVR assembly language.

author: brucehoult
author_rank: Super Contributor
timestamp: March 09, 2025, 01:19:09 am
content: Quote from: Analog Kid on March 09, 2025, 12:49:58 amSo do we.You're wasting the time of ten people.If you ask a question the absolute minimum of politeness would be reading the replies.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 09, 2025, 03:32:28 am
content: The enhanced mid-range series (16F1xxx and later) have49 instructions, which include logical shifts (no need to clear Carry, if you don't want it), some very useful addition with carry and subtraction with borrow instructions(1 cycle each),movlp and movlb (PCLATH and Bank respectively) bra, brw, callw, and indirect moviw/movwi with a choice or pre or post increment or decrement of the corresponding FSRn in 1 cycle (with exceptions).They don't have some of the nice PIC18F instructions , but it is still better than earlier 14-bit core 16Fxxx chips. You are still stuck with Banking for SFRs and RAM, but ALL of the user General Purpose RAM can be addressed linearly using an FSRn. That's nice for buffers. Common RAM is not affected by that.EDIT: I forgot to add that enhanced mid-range (PIC16F1xxx) added direct access to the stack. STKPTR is in Bank31. You don't have push and pop as commands per se, but you can do the same thing.

author: Tation
author_rank: Regular Contributor
timestamp: March 09, 2025, 08:32:57 am
content: Quote from: Analog Kid on March 09, 2025, 12:49:58 amExemplary...Yesterday you wrote 15 posts here ¿these are the other things you have to do? It's indecent on your part to continue asking for help just after ignoring the answers people prepared for you. Not nice at all.

author: beginner_max
author_rank: Newbie
timestamp: March 09, 2025, 08:35:34 am
content: it's ok, everbody do other things. Maybe he will look every few days in this thread, where is the problem.Then he can answer it.I don'a see any problem here

author: Smokey
author_rank: Super Contributor
timestamp: March 09, 2025, 08:52:07 am
content: There's only so many hours in they day... especially when you insist on making things artificially and unnecessarily difficult like writing asm code

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 09, 2025, 10:02:13 am
content: Quote from: beginner_max on March 09, 2025, 08:35:34 amNo actually it is not ok. When you ask a question on a forum and then are not bothered enough to read the answers given and just re ask to be given what has already being given plentiful, makes you a dick, at least in my eyes.We take the time to answer these questions and when you get responses like below, we might get miffed about it. At least I do. If every body was behaving like this guy, I would quickly loose interest in taking the time to help out.Quote

author: beginner_max
author_rank: Newbie
timestamp: March 09, 2025, 10:31:54 am
content: for me it is ok, any maybe for many others toI don't understand this drama like a queen:-).No problem here.No one need an answer in few hours or a day.You take time, and he take time, but no one says when you need to take the time.Are you angry to people, that not ask asap to your WhatsApp or read it?Maybe it's mor your problem then from other, maybe.Stay cool

author: OLderDan
author_rank: Regular Contributor
timestamp: March 12, 2025, 12:22:36 pm
content: After the first two pages of reading most everybody telling OP over and over again NOT to use ASM when this is specifically what he wants to use. It got so painful I skipped here to the end, and no wonder OP has gone awol. Guys, read back over this thread and look at how many times the posts are simply steamrolling over the original question with whatever is the personal flavour of choice.There were a few (looking at the awesome pcprogrammer for one) who genuinely seemed to have insightful comments directly relating to the original questions points, but again and again OP was having to reiterate that his choices were simply that, and nothing more, and he was looking for advice relating to his question.I am just off the back of reading some amazing helpful posts in the beginner section, and loving this place, and so I really hope my post is taken as constructive criticism, as intended.

author: shabaz
author_rank: Frequent Contributor
timestamp: March 12, 2025, 12:57:57 pm
content: It's perfectly reasonable to advise why assembly language isn't the best thing to gravitate toward; indeed, the OP himself concluded that RISC-V assembler syntax was too much for him.Lots of people read threads, not just the thread creator, so if it's directly helpful (which it still is), I don't see why advising against using assembler language for general typical microcontroller usage is a negative thing at all.It puts people off from wanting to contribute when there's clear rudeness from the original poster. I actually didn't contribute any suggestions at all because of what I read from the OP, not from the responses from others.If someone takes the time to give prima facie good advice, then it's basic politeness to at least consider it and see where they are coming from, not state, "You're zero for two," as the OP did to at least one commenter, amid further rudeness to others.

author: brucehoult
author_rank: Super Contributor
timestamp: March 12, 2025, 06:48:08 pm
content: Quote from: shabaz on March 12, 2025, 12:57:57 pmQuite ridiculously, as RV32I is significantly simpler to describe and learn than something like 6502 or Z80, let alone the PIC clone Ubicom SX-28 he says he used before. And then a good order of magnitude easier to actually get things done in. I say this as someone who to this day still writes 6502 and Z80 assembly language code (and have since 1980 or so).And, yes, the responses to not use asm are annoying, especially from people who clearly are not versed in it themselves and give factually incorrect information, just repeating what they read somewhere.

author: shabaz
author_rank: Frequent Contributor
timestamp: March 12, 2025, 07:09:07 pm
content: Quote from: brucehoult on March 12, 2025, 06:48:08 pmYou should know what they say about assumptions and what that makes you.We know RISC-V coding can be simpler than the archaic processor languages. Had the OP been open to it I might have recommended him a decent book, or shown him a very simple one-page reference.For a hobbyist with clearly no real interest in machine architecture and just wants to learn how to use a microcontroller, it's pretty clear that there's going to be a lot more hand-holding tutorials for something like C or Python.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 12, 2025, 07:39:34 pm
content: Quote from: brucehoult on March 12, 2025, 06:48:08 pmI have no idea about the RISC-V assembly, as I have not looked at it yet. Having used 6502, Z80 and 8051 assembly quite a lot back in the day, and you saying it is easier to learn it than those, I should not have any trouble with it then.The last assembly I looked at was ARM (armv5tej) when I reverse engineered the FNIRSI 1013D. Did not find it to difficult, but writing a full application in it would be cumbersome.Quote from: brucehoult on March 12, 2025, 06:48:08 pmIn a way it is admirable that someone has been writing assembly even on x86 under Windows OS, but also kind a stupid with the availability of higher level languages that perform just as well and allow you to get a large program up and running way quicker, no matter how experienced one is in assembly. Also when it has to be maintained for a longer period of time, by different people, assembly language is not the best choice.But who are we to judge if someone really wants to do it that way. The op has been presented with several options he asked for. Him not reading them is his business, but ignorantly asking again for the same thing is a no no in my book.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 13, 2025, 03:31:05 am
content: Quote from: pcprogrammer on March 12, 2025, 07:39:34 pmWell, if I might respond to that (I am the OP here, after all): not sure about "stupid".With me it's a matter of preference. If you missed it, I'm a hobbyist, not a production programmer: I have no time schedules to adhere to, no need for portability, no list of customer demands, no corporate guidelines, none of that; I'm free to pick the tools I want. And I just prefer assembly language, even for Win32 programs. Not because I like the relief one gets after stopping beating their head against the wall either: I just like the kind of directness I get from clean, working assembly-language code.And I'm not the only one. It's small, sure, but there's actually a "community" of us weird-ass programmers who prefer to do things this way.I'm even delving into code that's usually the domain only of C++ programmers: COM programming. It can be done in assembly language, revealing all those "methods" as just entries in a vtable.To me, it's fun.

author: brucehoult
author_rank: Super Contributor
timestamp: March 13, 2025, 05:06:27 am
content: Quote from: pcprogrammer on March 12, 2025, 07:39:34 pmLooking specifically at RV32I there are only 37 instructions, documented together in a single chapter, you can tell compilers to use it with-march=rv32i.This is 37 actual instructions to learn, not like 6502's 56 mnemonics, each of which can have up to eight different addressing modes, for 151 total instructions.There are 32 registers x0-x31 plus PC. All registers are identical and interchangeable except x0 is always equal to 0 (discards attempts to write to it). There is nothing else. In particular, no condition codes or status register.At the assembly language level there are only four kinds of instructions:- three registers rd, rs1, rs2:- rd = rs1 op rs2 where op is add, sub, and, or, xor, sll, srl, sra, slt, sltu That's 3 shifts, and 2 instructions that compare rs1, rs2 and set rd to 0 or 1- two registers rd, rs1 plus a sign extended 12 bit constant:- rd = rs1 op const where op is the above except sub (add the -ve instead)- rd = mem[rs1 + const] with size b, h, w plus unsigned option for b, w (LW, LBU etc)- rd = pc + 4; pc = rs1 + const (JALR)- two registers rs1, rs2, plus a 12 bit sign extended constant- mem[rs1 + const] = rs2 with size b, h, w (SW etc)- pc = pc + const if rs1 op rs2 where op is eq, ne, lt, ltu, ge, geu (BNE, BLT etc)- one register, rd, plus a sign-extended 20 bit constant- rd = pc + 4; pc = pc + const (JAL)- rd = const << 12 (LUI)- rd = pc + (const << 12) (AUIPC)That is IT. There is nothing more. With this you can efficiently compile all of C/C++ or any other language (using softfp if floating point is needed).Couple of minor wrinkles:- conditional branches and JAL support double the range (±4K, ±1M) by representing only even numbers. The binary encoding is a little more complicated than you might expect, but this affects only people writing assemblers or disassemblers or coding in binary/hex by hand.- link register and stack pointer do not exist in the ISA, any register(s) except x0 can be used for these functions. Standard tools and libraries use x1 for RA (LR) and x2 for SP. Some low level runtime library code uses x5 as a LR to avoid disturbing x1.- by convention certain registers use the mnemonic aliases a0-a7 (function argument / return / temps), t0-t6 (temps), and s0-s11 (locals preserved over function calls). There is also gp (globals pointer) and tp (thread-local globals pointer).Congratulation! You now know everything about RV32I.QuoteNot a bad ISA, but definitely more complex.QuoteSOMEONE has to know how to write asm, even if only people writing compilers. And emulators. And designing ISAs. And building hardware.It's not normally an efficient idea to write an entire application in asm in practise. It's too brittle to spec changes. It's unmanageable unless you follow a lot of conventions and boilerplate things in a way that makes code less efficient than a good modern compiler will. And it's non-portable to other ISAs. And will by definition only be optimised for a single µarch of even the same ISA.But knowing HOW is very useful, as is actually doing it for the odd critical function, especially if your CPU has instructions that don't map easily into C.

author: pcprogrammer
author_rank: Super Contributor
timestamp: March 13, 2025, 06:49:34 am
content: Quote from: Analog Kid on March 13, 2025, 03:31:05 amDon't get me wrong, I'm not calling you stupid. It is just to refer to the fact that there are options that make life easier when writing code.For what it is worth, writing proper code is not language related. It is more about logic, and on the almost lowest level there is indeed a more direct link between the logic. (The lowest level is the binary the processor is using)Quote from: Analog Kid on March 13, 2025, 03:31:05 amI did not miss that, as you can see from my posts herehttps://www.eevblog.com/forum/microcontrollers/suggestions-for-a-microcontroller-(general-purpose)/msg5840515/#msg5840515andhttps://www.eevblog.com/forum/microcontrollers/suggestions-for-a-microcontroller-(general-purpose)/msg5841591/#msg5841591Quote from: Analog Kid on March 13, 2025, 03:31:05 amEverything can be done in assembly language, just like I always say that (almost) everything can be done in C. Even object oriented programming can be done in assembly. And if that is what you like, who are we to judge.I myself would not like to go back on that road again. When needed I can use assembly, but if I can avoid it, I will. For me the clearness of C prevails.Quote from: brucehoult on March 13, 2025, 05:06:27 amThanks, looks simple enough.Quote from: brucehoult on March 13, 2025, 05:06:27 amKnowing the hardware is always a good thing. I recommend starting programmers to learn a simple ISA first to get some understanding about how the logic works. Can make you a better programmer.

author: forrestc
author_rank: Unknown
timestamp: March 13, 2025, 09:41:12 pm
content: Quote from: Analog Kid on March 13, 2025, 03:31:05 amSo, I used to code in Assembly and C. Nowadays, I never bother with Assembly. Why?C is essentially portable assembler. Every line in C can be directly assigned to some assembly directive, and if you look at the output of the C compiler, you'll often find exactly what you'd expect.a=12;equates to:MOVLW 12MOVWF <address of a>Once you realize that C is just a way to make assembler portable, C becomes less objectionable. In addition, modern optimizing compilers will produce output which is better/faster than most hand-written assembly. It can turn things like:a=12;b=10;c=a*b;into:MOVLW 120MOVWF <address of c>If a and b are not referenced anywhere else. There are a lot of other examples.I get it if you want to do something with assembly. It's fun to get down at that level. But C is so close to assembly that whether you write in assembly or C doesn't matter much. That's what people miss about why C still exists and is widespread - C is how you write what you used to write in assembly. C is a low-level language. It's designed to get really close to the underlying hardware. That's why kernels and embedded and all of those things are still written in C.The higher level languages (including some of C++) introduce a layer of abstraction between you and the hardware, which makes it more difficult to actually manipulate the hardware itself.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 13, 2025, 11:51:00 pm
content: Sorry, not sorry:I know all about C. Have written much C code (in an earlier life). And I know how low-level it is.I just prefer assembly. So please, save your breath and don't try to talk me out of it.

author: cunningfellow
author_rank: Regular Contributor
timestamp: March 14, 2025, 12:30:35 am
content: ASM is just much more fun.I do most my "work" in C (with ASM mixed in if needed).But when I want to "play" I prefer ASM.So I def see your point.

author: Picuino
author_rank: Super Contributor
timestamp: March 14, 2025, 09:44:00 am
content: I think that if you want to program in ASM, that the micro can be used for all types of projects (small, medium, large) with the same instruction set, that it is a bet with future, it is best to bet on the ARM architecture.There are many manufacturers that use the ARM core. STM32 for example is one of the best known with cheap development boards and a free IDE, very interesting to start with.https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html

author: brucehoult
author_rank: Super Contributor
timestamp: March 14, 2025, 10:27:13 am
content: Quote from: Picuino on March 14, 2025, 09:44:00 amArm is indeed everywhere, but if you're programming in assembly language then you have to consider that there are in practical terms three different Arm instruction sets that despite family similarities you have to treat quite differently in asm, even for just the the simple integer load/store, add/sub/and/or/xor/shift, compare/branch functionality that you use absolutely everywhere in the code.If you're using a compiler then you can ignore the differences.First, the 64 bit ISA is almost completely different to 32 bit. You've got so many registers you'll probably never have to think about running out. With 8 function argument registers (assuming you follow convention, so you can interoperate with library or compiled code) you'll almost never run out except maybe in the most complex printf. It's a very powerful but very complex ISA.Then in 32 bit, as well as having not very many registers and only four function argument registers -- far easier to run out of -- for the "small" projects the Cortex-M0 is very restrictive to program. You only have full use of eight of the registers. You don't get predication. You don't get combined arithmetic and shift. There are all kinds of different restrictions on immediate values and offsets for different instructions, different offset ranges for load/store of different types. You really have to think quite hard to take full advantage of it.You can run CM0 code on the medium sized CM3/4/7/33, but it's not going to make the best use of them.Sure, if you just want to write in asm and have itworkthen it's not hard -- but if we're not trying to get the most out of the chip and use it at least as effectively as a compiler would, if not better, then why are we even bothering? You really need to understand the nooks and crannies of each variant to get the most out of it.

author: Picuino
author_rank: Super Contributor
timestamp: March 14, 2025, 11:29:38 am
content: Just thinking about it is tiring.I much prefer to use C as you would in assembler (with gotos included).

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 14, 2025, 12:38:54 pm
content: What was really tiring was programming in assembly for the old PIC 8-bitters with their banking system, you had to keep track of the current bank at all times (that is, if you didn't want to incur the penalty of switching banks at every single access which would be horrible).There is no question as to how using a higher-level language is beneficial for development time and maintenance.Still, things as complex as compilers and even full OSs have been written all in assembly (something people would rarely bother with these days, but we can mention Menuet OS:https://www.menuetos.net/).For that, you need to document all your routines' interfaces very clearly and thoroughly to make it remotely maintainable. That's a lot of work.

author: Picuino
author_rank: Super Contributor
timestamp: March 14, 2025, 12:49:24 pm
content: PIC 8 bit architecture is horrible for many reasons. The stack to store only 8 addresses in some micros may be another one of them.In fact C was invented in the early 70's precisely to make Unix portable on machines that then hadaround 32kbytesup to 256 kbytes of ram memory, which is common today on a mid-range microcontrollers.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 14, 2025, 02:20:37 pm
content: Quote from: Picuino on March 14, 2025, 12:49:24 pmPlease review the 8-bit, 21st century PIC's released 15 years ago. The stack is 16 levels and is readable and writable plus several other enhancements as I described earlier in this thread. You may not like the Harvard architecture, butthey workit works well, particularly in Assembly.Edit: Grammer as shown

author: bson
author_rank: Unknown
timestamp: March 14, 2025, 09:19:57 pm
content: About the only architecture I'd recommend against is ESP32 - these are built around Cadence Xtensa, an IP core family with very limited documentation out of NDA. It's also highly configurable, so each vendor can customize it for their needs. It has never been intended to be a general-purpose processor so just doesn't have that type of manuals, guides, and documentation. Espressif also only documents some of their peripherals, at least in English, and you become dependent on using their libraries for anything else. These factors in combination IMO make the ESP32 family totally unsuitable for tinkering with in assembly.I'd strongly suggest ARM Cortex-M or RISC-V. They're easy to work with, are well documented, future-proof, and come in a wide variety of models for everything from operating off a button cell for years, to multi-core monsters running at 600MHz or up.

author: brucehoult
author_rank: Super Contributor
timestamp: March 14, 2025, 09:44:41 pm
content: Quote from: bson on March 14, 2025, 09:19:57 pm"ESP" is a brand not an ISA. Early members used Xtensa but different variants -- ESP8266 is LX106, the original ESP32 used LX6 and later models LX7. Recent ESP32, and all future models according to the company, are RISC-V e.g. ESP32-C3, ESP32-C6, and ESP32-P4QuoteCorrect. And I think Cadence may even not have been very happy when Espressif started supporting customers writing their own code and documenting the ISA so they could do that.I was once working on software for an embedded product at Samsung. The (internal only!) ISA documentation simply described the instructions and their encodings. I observed that there were both 2-byte and 3-byte instructions and said to myself "that's interesting". I checked against ESP32 documentation. Yup, mostly identical.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 14, 2025, 11:00:39 pm
content: There's one place where assembler is head and shoulders about anything else. That is learning. If you want to learn how a CPU works (whether the CPU in general, or your particular CPU) your best bet is to write a few programs in assembler.Perhaps creating a small CPU from logic ICs (or in FPGA) will teach you even more about CPUs, but that's another story.

author: jpanhalt
author_rank: Super Contributor
timestamp: March 14, 2025, 11:52:58 pm
content: I still suffer Assembly, but my excuse is simple. In 70's to 80's, I acquired a TI-99 at home and a very early version an IBM PC at work. We used IBM Basic at work and got a decent project up and running. It was finally retired in about 2010. I didn't do much after that until about 2000 when I wanted to replace some discrete logic with an MCU. I looked at the PIC12F509. I was just like flowcharting that I had done my whole professional life, except with a relatively small number of mnemonics that were easy to remember. Over the years, often when bored, I will pick some computation and try to solve it. I have lots of code to do stuff PIC's don't do with simple instructions, like bin2dec, division, hourly clocks, BCD addition and subtraction, etc. I wouldn't call them libraries, but they are easily copied and pasted. I see no reason to change now.It's a little like learning to drive with a stick shift. You never forget the fun of popping the clutch at a stop light or with a girl next to you. If I had started with MCU's in an academic setting with C, I might feel the same about using C today.

author: brucehoult
author_rank: Super Contributor
timestamp: March 15, 2025, 12:33:34 am
content: Here today we have an amusing example of someone asking "I hand wrote my tensor product and tensor contraction code in asm ... but it's slower than NumPy .. how can this be??"ahahahahttps://www.reddit.com/r/asm/comments/1jb80yz/my_code_in_nasm_took_more_time_running_than_numpy/

author: Analog Kid
author_rank: Super Contributor
timestamp: March 15, 2025, 01:18:35 am
content: Heh; so much for the "everything is faster if written in assembly language" misconception.

author: brucehoult
author_rank: Super Contributor
timestamp: March 15, 2025, 01:43:16 am
content: NumPy might well have kernels written in asm, I don't know. It will certainly be using at least x86-specific SIMD intrinsics in C, unrolling, I assume cache blocking. It's state of the art stuff.

author: phil from seattle
author_rank: Super Contributor
timestamp: March 15, 2025, 04:57:08 am
content: Quote from: Picuino on March 14, 2025, 12:49:24 pmCut my teeth on a Unix V6 system on a PDP-11/45 which maxed out at 256KB RAM. 32 simultaneous users. Those were the days! Banged a little ASM on it but with C you could do some amazing things. I wrote a complete compiler in one semester - lex/yacc/code gen all in C. Made me true believe.Sorry for the diversion, back to the "why would anyone want to use ASM" discussion in progress.

author: phil from seattle
author_rank: Super Contributor
timestamp: March 15, 2025, 04:59:04 am
content: Quote from: NorthGuy on March 14, 2025, 11:00:39 pmIf you want to REALLY understand how a CPU works, write a compiler for it. Talk about drinking from a fire hose.

author: brucehoult
author_rank: Super Contributor
timestamp: March 15, 2025, 07:06:00 am
content: Quote from: phil from seattle on March 15, 2025, 04:57:08 amMine was an 11/34 with the same amount of RAM and 30 users in one room (lab) plus 2 LA120 printers.The year before me they learned FORTRAN and had an environment where when you submitted your program to compile you were logged off for someone else to use that terminal, and you went to the printers to await your compiler listing and porribly program output.In my first year we used Pascal. Asking to compile added your program to a batch queue, so there was only one copy of the compiler at a time, but you stayed logged on and could run the binary (if you got one) as much as you wanted and even keep it as long as your total disk usage was under IIRC 32 blocks when you tried to log off. I helped find and fix a bug in the NBS Pascal compiler we were using, where it hallucinated that the PDP-11 had an Add Byte instruction -- it did have bytes versions of CLR, INC, DEC, ADC, SBC, TST, NEG, COM, ROR, ROL, ASR, ASL (all single operand instructions) and MOV, CMP, BIS, BIC, BIT (two operand instructions) but the encoding you'd imagine was ADDB (and the compiler did) was actually SUB.But that was running, I think , RSX. My introduction to Unix was a couple of years later on a Zilog System 8000 (Z8000 CPU).

author: Tation
author_rank: Regular Contributor
timestamp: March 15, 2025, 11:47:48 am
content: Quote from: brucehoult on March 15, 2025, 01:43:16 amnumpy uses LAPACK and so uses some BLAS incarnation (openBLAS, oneMKL,...). openBLAS definitely contains hand-tuned, cache-aware and friendly, assembly kernels (and I suppose oneMKL also does, as its performance is comparable to that of openBLAS), so not strange at all that some random guy over Internet, not devoting years to the task, cannot beat numpy, no matter if using assembly, C or whatever.

author: osmax_br
author_rank: Regular Contributor
timestamp: March 15, 2025, 12:02:32 pm
content: I see a lot of these RISC-V MCUs by sipeed , some of them cost 3$ with more performance than esp32 s3 for exampleHave anyone tried one of those before?However the software support seems very little to not existent

author: Picuino
author_rank: Super Contributor
timestamp: March 15, 2025, 04:09:39 pm
content: Both LAPACK and BLAS are written in Fortran language.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 15, 2025, 06:08:40 pm
content: Quote from: phil from seattle on March 15, 2025, 04:59:04 amCompiler is a program which writes assembler, most of them anyway.

author: phil from seattle
author_rank: Super Contributor
timestamp: March 15, 2025, 07:37:57 pm
content: Quote from: NorthGuy on March 15, 2025, 06:08:40 pmSome do but, regardless of the intermediary form, you have to understand the underlying architecture completely (which was my point). Then you get to worry about things like out of order execution and others peculiarities.

author: Tation
author_rank: Regular Contributor
timestamp: March 15, 2025, 09:25:14 pm
content: Quote from: Picuino on March 15, 2025, 04:09:39 pmLAPACK still is mainly FORTRAN, with some C, but current implementations of BLAS no longer rely so heavily on it and do contain assembly.

author: westfw
author_rank: Super Contributor
timestamp: March 17, 2025, 02:24:22 am
content: Hmm. I had this thought:RISC Architectures:SPARC: dead.PA-RISC: dead.ALPHA: dead.PPC: mostly dead ("Niched"?).MIPS: mostly dead.XTensa: barely ever achieved any popularity, from a manufacturer that is now "moving on."ARM: mutated nearly beyond recognizability. (ARM32 was pretty elegant. Thumb2 with all the bells and whistles added - not so much. (personally not familiar beyond the microcontrollers, though.))RISC-I through RISC-IV: not commercialized? (SPARC is based on one of them?)CISC Architectures:8080/Z80: not taking over the world, but arguably doing as well as it ever did.8051: still going strong.X86: still going strong (maybe "mutated", like ARM?)(8bit)PIC: still going strong. (they call it "RISC", but the only thing it has in common with modern RISC is "few instructions.")So it sort-of looks like having really stubborn manufacturers is more important than architectural elegance, if you're looking for longevity...(although, from a PROGRAMMING PoV, there are a lot more similarities between different RISC architectures than between different CISC architectures.)(So, are "register windows" pretty much an abandon concept?)

author: brucehoult
author_rank: Super Contributor
timestamp: March 17, 2025, 03:57:47 am
content: I'm not sure your taxonomy holds up.8080/z80, 8051, PIC are not really either CISC or RISC. More Impoverished Instruction Set Computer. They mostly have quite RISC-like register-to-register instructions, with load/store separated out, except for being able to use the "M" register on 8080 aka "(hl)" on z80 (and "(ix+n)", "(iy+n)" on z80) on a lot of arithmetic instructions. Apart from "M" all memory references are only by LDA/STA (nnnn) and PUSh and POP, they are not mixed with arithmetic. And there is at most one memory operand per instruction.Even x86 has at most one memory operand per instruction, which separates it from all the dead CISC.You didn't mention the dead CISC! VAX. M68000. NS16000/32000. Pr1me. iAPX432. Interdata 7/32. HP3000. Data General Eclipse.Those are so thoroughly dead that most of them have been memory-holed.And compared to them, all the "CISC" you list are only a small step from being RISC too.RISC-I through RISC-IV were student projects. The first two were just experiments to see if the RISC idea worked at all. The last two were testing the RISC idea applied to Smalltalk SOAR (Smalltalk on A RISC) -- instead of the very CISC special purpose LISP and Smalltalk and Prolog machines proposed up to that date -- and SPUR which was a full set of chips to build a 32 bit workstation.SPARC is in fact based on the RISC I / RISC II ideas.Dave Patterson himself now says register windows were a bad idea, which they would not have implemented at Berkeley if they had as good compiler technology in the early 80s as Stanford had for MIPS.XTensa is from what I understand everywhere! You just never see it or hear about it because until Espressif no one who used it ever exposed it to allow the end user to program it. I believe Cadence was not happy about Espressif doing that, and releasing documentation on it.

author: rsjsouza
author_rank: Super Contributor
timestamp: March 17, 2025, 11:09:12 am
content: I suspect you are correct; I vaguely recall that, in the RISC/CISC discussions of the early 1990s, one of the arguments that "x86 will be killed by the modern RISC architectures" was due to the presence of a few multi-cycle instructions that were despised by the RISC initiative. As with everything, "where there is a will there is a way", the x86 was modified to accommodate RISC-like architectural features after some startups came with their "front ends" for x86.Interesting article:https://www.extremetech.com/extreme/323245-risc-vs-cisc-why-its-the-wrong-lens-to-compare-modern-x86-arm-cpus

author: TomKatt
author_rank: Frequent Contributor
timestamp: March 17, 2025, 11:17:03 am
content: Quote from: phil from seattle on March 15, 2025, 04:59:04 amBack in the day, I did just that for my C64. Not only did I learn asm, but when you get that deep in the weeds you start seeing the relationships between the instructions from their binary bit patterns... I recall that I could determine things like what type of branch an opcode was using by certain bits in the opcode. Then you can start to envision how the cpu translates the opcode bits into the various command actions. Really very interesting.BUT - been there, done that. I have better things to do with my time these days lol. Give me a good high level language so I can get my project done - memory and speed are cheap these days. That said, I still code many AVR projects in BASIC (Bascom AVR)

author: brucehoult
author_rank: Super Contributor
timestamp: March 17, 2025, 11:57:05 am
content: Quote from: rsjsouza on March 17, 2025, 11:09:12 amThat's about implementation techniques. RISC/CISC is about the instruction set, which is an immutable property. A statement such as "386 is CISC but Pentium III is RISC" are nonsense since they execute the same instructions.The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.As an example, if local variables A, B, and C are pointers to integers and the variables are stored in the stack frame then on the VAX you can do*C = *A + *BasADDL3 @B(SP),@C(SP),@A(SP)This instruction is 7 bytes long, and does 5 memory loads and one store. It demonstrates both multiple memory operands and indirect addressing.Even "CISC" x86_64 needs six instructions (and 24 bytes of code) to do the same thing the VAX can do in one. Arm64 also needs six instructions and 24 bytes of code. RISC-V needs seven instructions but only 14 bytes of code.Code:2b:48 8b 44 24 08mov 0x8(%rsp),%rax30:48 8b 00mov (%rax),%rax33:48 8b 54 24 10mov 0x10(%rsp),%rdx38:48 03 02add (%rdx),%rax3b:48 8b 54 24 18mov 0x18(%rsp),%rdx40:48 89 02mov %rax,(%rdx)Code:24: a940a3e9ldpx9, x8, [sp, #8]28: f9400108ldrx8, 2c: f9400129ldrx9, 30: 8b080128addx8, x9, x834: f85f83a9ldurx9, [x29, #-8]38: f9000128strx8, Code:18:67c2lda5,16(sp)1a:639clda5,0(a5)1c:6722lda4,8(sp)1e:6318lda4,0(a4)20:97baadda5,a5,a422:6762lda4,24(sp)24:e31csda5,0(a4)Only one of the x86 instructions is slightly non-RISC in loading from memory and adding to %rax in one step. That's why the x86 is fewer instructions than the RISC-V.Arm64 is one instruction fewer than RISC-V because of the "load pair" instruction to load B and C into registers.Incidentally RISC-V recently added load pair and store pair instructions as a standard extension for the 32 bit ISA only -- using the opcodes used for load/store double in the 64 bit ISA.

author: westfw
author_rank: Super Contributor
timestamp: March 17, 2025, 10:35:38 pm
content: QuoteUm.movsb/movsw/etc.Many math instructions allow memory as src/dest to be memory, meaning at least RMW memory cycles. Those include operations with immediate values; nominally also memory references ("addl $0xdeadbeef, (%edi)" or something like that.)lds/etc loads two words of memory (not a big deal any more, but definitely more than one memory cycle back in the 8086 days. (my "good" knowledge of x86 doesn't go much past 8086.))QuoteAh. True.68k lives (limps) on as "Coldfire" (now at NXP), along with several other old Motorola archs.I'm not sure that the "highly proprietary" architectures should count? Mainly I'm talking about those that have been highly touted as "standards" (MIPS, PPC) or become defacto standards (eg 8051)QuoteExcept that the registers aren't even close to "general purpose" (which I consider an important aspect of RISC.) The "Accumulator" architectures are a relatively important subset, at least historically. A lot of their CISC-ness seems to come from "well, we want to do SOME things without using the AC; what can we actually implement?")QuoteI'm pretty sure that the first Xtensa instruction set manual I downloaded was direct from Cadence (although also IIRC, not easy to find.) Copyright 2013, so that might have been reactive rather than "voluntary."

author: westfw
author_rank: Super Contributor
timestamp: March 17, 2025, 10:44:12 pm
content: QuoteI'm not sure about that. You can write a "pretty good" compiler using only a fraction of the features of a CPU.In fact, that's part of the anti-CISC argument - designers were adding all sorts of instructions to their architectures that were nearly impossible for compiler writers to use effectively in a program (sure, you could have your aged assembly language programmers use them in libraries, but ... that was less interesting.)You also see this with the "un-optimized" code that comes out of some compilers (avr-gcc with -O0 and certain versions of the Microchip PIC compiler in "free" mode, for example.)I was very unhappy when the compiler class I took in college spent so little time on optimization, or even converting generic 3-operand instructions to code for a specific CPU. But that used to be where a lot of compiler writers stopped.

author: TomKatt
author_rank: Frequent Contributor
timestamp: March 17, 2025, 10:58:17 pm
content: Quote from: westfw on March 17, 2025, 10:44:12 pmI'd suggest that compiler optimization is a tenure of it's own compared to simply converting commands into asm opcodes... It's rather straightforward to match asm and addressing options. but determining the most efficient sequence of instructions is much harder. Not to mention that 'optimized' doesn't really have a definition... Speed? Size? Readability? Writing a good compiler is no easy task.

author: brucehoult
author_rank: Super Contributor
timestamp: March 17, 2025, 11:24:09 pm
content: Quote from: westfw on March 17, 2025, 10:35:38 pmI specifically said "normal instruction". The string instructions stand apart from the rest of the ISA, and while compact in code they have except in the very first chips usually been microcoded and considerably slower than a loop of normal instructions.QuoteThat is one memory operand. One address. One use of the page tables or other address translation or access control mechanism.RISC-V and Arm also have RMW instructions e.gAMO{ADD,AND,OR,XOR,SWAP,MIN,MINU,MAX,MAXU}in RISC-V.Some implementations actually execute these deep in the memory system not on the CPU e.g. in a cache controller or even in a peripheral on its registers. This is supported in Berkeley's "Tilelink" TL-UH bus's ArithmeticData and LogicalData message types. I believe recent AMBA specs support something similar.Some implementations trap to M mode and then use LR/SC to implement them e.g. "LR; add; SC; BNE retry"And some implementations actually execute a RMW in the CPU.QuoteEssentially the RISCish subset of 68k.Quotex86 is highly proprietary.MIPs and PPC were highly proprietary until they got into trouble.Others copy successful ISAs, whether they are proprietary or not, sometimes leaving out the patented parts (Loongson) or simply waiting for any patents to expire (8051).QuoteRegister-rich accumulator ISAs are certainly RISC, just a less convenient subset of it. Sure it's nice to be able to do "A += B" or "A = B + C" for arbitrary choices of registers, but saying "the dst can only be A" in order to reduce the number of bits in an instruction is a valid choice within RISC, and a further restriction not a violation.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 18, 2025, 02:11:41 am
content: Quote from: westfw on March 17, 2025, 10:44:12 pmSome basic things which may seem easy, such as optimizing register assignments, are not that easy to implement. You can communicate some ideas on what can be done and where to start, but going into details is way too much for a compiler class.

author: brucehoult
author_rank: Super Contributor
timestamp: March 18, 2025, 02:44:45 am
content: Quote from: westfw on March 17, 2025, 10:44:12 pmThat depends on the CPU!RV32I is a nice fit for compiling all of C/C++  and similar languages, with just 37 instructions, every one of which is used by the compiler, given suitable source code. Of course if your program doesn't do any XORs then the XOR instruction won't get used etc.QuoteThat is true, but it's even worse than that -- those instructions were often just convenience for assembly language programmers, but actually executed slower than using several simpler instructions. Patterson found many examples of this for VAX 11/780, and Cocke for IBM System/370.Your aged assembly language programmers should not even use them in libraries, only in quickly written application code where programmer productivity was more important than machine efficiency.QuoteI took compiler classes at university in 1983/4 and actually worked on back-ends for VAX and M6809.We certainly covered .. and implemented .. the most important optimisations such as constant expression evaluation, strength reduction, common subexpression elimination, code motion out of loops.We studied and implemented register allocation but the algorithms at the time were pretty crude. Patterson has said that RISC-I and RISC-II would never have used register windows if they'd known a good register allocation algorithm for their compiler.One of the largest amounts of time spent was on trying to match address calculation DAGs to all the crazy addressing modes, and figuring out when to use arithmetic rather and an addressing mode, and when to bail out of trying to match the whole address calculation DAG to an addressing mode and just emit an LEA with what you had, and then start again from that.And using complex addressing modes was at odds with common subexpression elimination (and still is today with x86 and Arm scaled indexed addressing).Pure RISC with no more than base+offset addressing is SO MUCH easier to generate code for. You just need a few more instructions and a few more temporary values in registers. But those are easily subjected to all the normal optimisations -- common subexpression elimination, moving some of it out of loops, etc. with soft float used if the program uses FP, you can add F or D extensions if this is performance-critical.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 18, 2025, 03:52:44 am
content: Quote from: brucehoult on March 17, 2025, 11:57:05 amUm:Code:MOV EAX, Isn't that indirect addressing?

author: brucehoult
author_rank: Super Contributor
timestamp: March 18, 2025, 04:15:29 am
content: Quote from: Analog Kid on March 18, 2025, 03:52:44 amNope. There's only a single memory access there. It's what M68000 calls "register direct" e.g.MOV (A4),D1. Register indirect, introduced in the 68020 (and not present in 68000 or x86) isMOV (),D1which takes the contents of A4 as an address, loads a word from that address, and uses that data as the address of the item to load into D1.In full 68020 can do (where bd and od are constant integers):([bd,An),Xn.SIZE*SCALE,od) // EA = (bd + An) + Xn.SIZE*SCALE + odor([bd,An,Xn.SIZE*SCALE],od) // EA = (bd + An + Xn.SIZE*SCALE) + odOr you can do a LEA with one of those to load EA into an address register and then continue from there.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 18, 2025, 05:00:15 am
content: Quote from: brucehoult on March 18, 2025, 04:15:29 amI hate to get into a nitpicking session with you, but I think you're using the term "indirect addressing" contrary to what other sites I just found in a search say it is.This pagesays:QuoteThis pagesays:QuoteBoth of which jibe with my understanding of the term.

author: brucehoult
author_rank: Super Contributor
timestamp: March 18, 2025, 07:46:27 am
content: Quote from: Analog Kid on March 18, 2025, 05:00:15 amWith the greatest respect, there is a difference between "web pages I just found" and knowing.QuoteThe description of what that instruction does is correct. The name is not correct. That is just "register" addressing.QuoteThe text description is correct. The instruction tells you a MEMORY location to access. The data you get from that location is the address of the data you actually want. The instruction then uses the just-loaded data as an address for a second load.x86 does not have any such instruction to do that. The “MOV AX, ” merely uses that is in the BX register as the final address of the data you want, as does the 68020 "MOV (A4),D1". It does not load a pointer from that address and then make a second memory access as the 68020 "MOV (),D1" instruction with register indirect addressing does.The diagram at that web page shows what is called "absolute indirect" addressing rather than register indirect (where the instruction contains or implies a register in the CPU that holds the first address).If they want to call it "memory indirect" rather than "absolute" indirect that's ok with me.BUT if you want "register indirect" then you simply replace the "address" in the instruction with a "register number" in the instruction, and keep the rest of the diagram. The CPU register contains the address for the first load, the data loaded is the address for the second load.That is not what the x86 “MOV AX, ” instruction does. Unlike PDP11, VAX, M68020 the x86 does not have an instruction that does that.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 18, 2025, 02:52:04 pm
content: "direct" means something specified within the instruction, "indirect" means that the instruction contains a reference which specifies where the object can be fetched from at run time.If you apply this to the memory accesses, then "direct" would mean that the address is hard-coded within the instruction. Everything else is "indirect".Here's from the official description of Intel ISA:"The following addressing modes suggest uses for common combinations of address components.• Displacement ⎯ A displacement alone represents a direct (uncomputed) offset to the operand. Because thedisplacement is encoded in the instruction, this form of an address is sometimes called an absolute or staticaddress. It is commonly used to access a statically allocated scalar operand.• Base ⎯ A base alone represents an indirect offset to the operand. Since the value in the base register canchange, it can be used for dynamic storage of variables and data structures.... "In x64, the commands don't really access absolute addresses, but only offsets, so all the addresses are relative. However Intel don't change the terminology to reflect this. They see the difference between direct and indirect in whether the address is embedded within the instruction (direct) or the instruction contains only a reference to where the address would be found at run time (indirect).

author: brucehoult
author_rank: Super Contributor
timestamp: March 18, 2025, 11:37:36 pm
content: Quote from: NorthGuy on March 18, 2025, 02:52:04 pmNote that the actual name of the addressing mode there is "Base", which I fully agree with.The use of the word "indirect" there is informal English description, not the name of the addressing mode.When CPU architects say that the problem with CISC is the indirect addressing modes -- and they do -- what they mean by that isnota register holding the address of the data. Everything does that. Or at least everything that supports pointers and stacks in RAM. What they mean is instruction -> reg number -> contents of that register as a pointer -> load data from memory -> interpret that data as a pointer -> load data from memory -> use that data.Intel of course doesn't have a term for that as Intel doesn't have that feature. VAX does that. M68020 does that. Data General does that. Pr1me does that. NS32000 does that.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 18, 2025, 11:47:08 pm
content: Quote from: brucehoult on March 18, 2025, 11:37:36 pmCould you please provide a source for that assertion?In my search, every single page I found did not so describe "indirect addressing".Your definition seems quite overly restrictive to me.I'm fine with being proven wrong here.

author: brucehoult
author_rank: Super Contributor
timestamp: March 19, 2025, 12:50:29 am
content: Quote from: Analog Kid on March 18, 2025, 11:47:08 pmhttps://yarchive.net/comp/risc_definition.html"3d) Have NO indirect addressing in any form (i.e., where you need one memory access to get the address of another operand in memory)"See "PART II - ADDRESSING MODES" and "THE GIANT ADDDRESSING MODE TABLE". His "r" ... Register addressing mode ... means the register contains the address of the data. That's the only addressing mode (per the table) on AMD 29K.John Mashey is one of the most respected CPU architects ever. This is the standard terminology in comp.arch and for CPU architects everywhere.https://en.wikipedia.org/wiki/John_MasheyRead the whole thing.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 19, 2025, 01:01:35 am
content: Quote from: brucehoult on March 19, 2025, 12:50:29 amWTF? Thanks, but no thanks.What, are you nuts? This is a breathtaking ask, and is so typical of some of the responses one gets here:"Here, read my 242 page document and then you can respond."Do you realize how much text is in that document?I'm somewhat interested in the topic here (indirect addressing), but I'm not about to drop everything and spend the hour and a half it would take to read and digest that! It's not that pressing an issue to me.Have some sense of proportion, man.Sheesh.

author: Andy Chee
author_rank: Super Contributor
timestamp: March 19, 2025, 01:24:33 am
content: Quote from: Analog Kid on March 18, 2025, 11:47:08 pmMy basic understanding comes from the 16F84 datasheet (page 13 & 14)https://ww1.microchip.com/downloads/en/devicedoc/35007b.pdf(which incidentally, is the same as Ubicom/Scenix SX28)

author: brucehoult
author_rank: Super Contributor
timestamp: March 19, 2025, 01:33:39 am
content: Quote from: Analog Kid on March 19, 2025, 01:01:35 amYou asked for a source. That's a definitive and highly respected source. Why even ask if you're not even intending to read it?If you want to understand the issue then an hour and a half is nothing. I've spent decades studying computer architecture -- as in, I took the time to read and understand that post (and many others like it, and text books) at the time it was made in the early 90s.And I put in an hour or an hour and a half researching and answering people's questions here or on reddit etc almost every day.If you don't want to put in the work yourself, then maybe believe those who have?Just a thought.

author: shabaz
author_rank: Frequent Contributor
timestamp: March 19, 2025, 01:35:06 am
content: Here's what Hennessy & Patterson have to say on the subject (2nd edition; I don't own the latest), see rows 4 and 7.

author: brucehoult
author_rank: Super Contributor
timestamp: March 19, 2025, 01:47:50 am
content: What CPU designers hate, and RISC ISAs don't have and CISC ISAs do have (except x86 .. one reason it's the only surviving CISC) is the 7th mode in that table "memory indirect" which is usually abbreviated to "indirect". I would suggest that the first listed name for each mode is their preferred one, though it does seem that Intel uses the second name.The entire point is that the 7th addressing mode is bad, no matter what it is called, and machines that have it are now all dead.

author: Analog Kid
author_rank: Super Contributor
timestamp: March 19, 2025, 02:45:42 am
content: Well then, from that I conclude that what I've been calling "indirect addressing" is in fact what it is (4th table entry, "register deferred or indirect"), while the overly-qualified mode you've been claiming as "indirect" (7th entry) is "memory indirect or memory deferred".Therefore, at least according to this source,Add R4, (R1)does qualify as "indirect addressing".Or do you dispute that?

author: brucehoult
author_rank: Super Contributor
timestamp: March 19, 2025, 03:29:16 am
content: Quote from: Analog Kid on March 19, 2025, 02:45:42 amLet me try to use very small words for you.WhenCPUdesignerssayindirectaddressingisbadtheydoNOTmeanaregisterholdingamemoryaddress

author: westfw
author_rank: Super Contributor
timestamp: March 19, 2025, 09:31:41 am
content: The DEC PDP10 architecture had very explicit “indirect” addressing. There was a bit for it in the instruction (36 bits makes for a lot of options.). Each instruction would calculate an “effective address” based on an index register (possibly none) plus displacement. If the indirect bit was set, it would fetch a word from that address, and do the whole effective address calculation AGAIN.All before the opcode evaluation. You could end up with an infinite loop, just in the address calculation!I actually used this with two index registers once, to implement a sort of two-dimensional array.And it was useful with some of the legacy subroutine linkage methods that stored the return address in “weird” memory locations.

author: brucehoult
author_rank: Super Contributor
timestamp: March 19, 2025, 10:04:19 am
content: Quote from: westfw on March 19, 2025, 09:31:41 amYes, this was common at the time.In the Data General line, in the Nova (PDP-8 competitor) LDA and STA had an indirect bit in the opcode, which resulted in the memory operand being treated as the address of the data, not as the data itself. This worked only for a single level , but the JMP instruction also had an indirect bit, and in this case if the MSB of the data loaded was 1 then next word loaded would also be treated as indirect. This could form an infinite loop. In the Eclipse (still 16 bit but added a stack pointer, floating point registers, and virtual memory) the load and store instructions also supported infinite levels of indirection. This was carried over to the 32 bit Eclipse/MV.