5 ms·

Has nothing to do with 8-bit. Deep OS level knowledge can and should be taught starting from 64 bit (where most OSs run) and maybe tiny speck of 16 bit because

Has nothing to do with 8-bit. Deep OS level knowledge can and should be taught starting from 64 bit (where most OSs run) and maybe tiny speck of 16 bit because most BIOS still runs on 16 bit intel It's about exposure to syscalls, C, assembly, lower level debugging and just making sure people aren't afraid to touch that layer. Same goes with other foundational knowledge like packets and networking protocols

klelatti 3y ago
Are you suggesting that 'Deep OS knowledge', syscalls, C, assembly, packets and networking protocols should be taught in schools? What I think the author is getting at with '8-bit' is that presenting children with a complete machine that is simple enough to understand from top to bottom gives a foundation that they can build on when they encounter more complex systems later on.
- adrian_b 3y ago
  The 32-bit ARMv7-M micro-controllers with Cortex-M4 or Cortex-M7 cores that are available for instance on $10 development boards from ST or from many other companies are conceptually simpler and easier to understand when programmed at the bare-metal level than the 8-bit computers of 40 to 50 years ago. They are a much better target for teaching children about hardware.
  - FirmwareBurner 3y ago
    Hard disagree. 8 bit micros are far simpler to understand from every perspective and depth than the 32 bit micros. One of the main benefits of teaching on 8 bit micros is they function like basic HW Harvard state machines, meaning their code execution is easily predictable and explainable form the diagrams on paper/whitrebaord, to the disassembly in the debugger in practice, as every CPU instruction takes exactly one clock cycle, there's no memory caching, no PLL and various multipliers and dividers for the 50 on-chip clock domains and IRQ tables, but they have on single clock from an external oscillator from which the CPU, RAM and FLASH memory, and all peripherals run on only that clock meaning it's easier to draw clock/signal diagrams to show "on this rising edge the CPU fetches the instruction, on the next clock edge, the ADC triggers the sampling, etc" Secondly, 8 bit micros come in DIP packages easier to breadboard and are 5V tolerant meaning you can just hook them up to USB, and most of the times they have high current pins with Schottky diodes meaning you can have them rectify AC voltage or direct drive LEDs without transistors. Thirdly, IMHO, 8bit ASM disassembly, like the Atmega AVR, is much easier to follow and understand in the debugger for beginners than the 32 bit ARM due to lower instruction count and simpler less powerful instructions that are always 8 bit, and less features that can confuse you like configurable IRQ tables or powerful instructions that cand do two operations at once per clock cycle for extra performance or optimized instructions that are 16 bit instead of 32 bit to save code space like the ARM Thumb. 8bit micros like the old Arduinos are far ore capable for learning and hobbyist tinkering than people give them credit for. People just needlessly fixate against them because "32 bit is bigger than 8 bit". My $0.02.
    - spease 3y ago
      > If you wanna play with 32 bit machines to understand how they work you can just build and debug 32 bit code on your x86_64 machine, no need to go embedded. That’s like comparing a sand castle to a hospital complex. You might want some intermediate steps in between.
      - FirmwareBurner 3y ago
        Indeed, that was a dumb statement on my part. Edited.
    - adrian_b 3y ago
      I have begun learning about computer hardware many years ago on computers with 8-bit Intel 8080, Zilog Z80 and Motorola MC6809 CPUs and I was among those who could read hexadecimal Z80 machine instruction codes as easily as a source text in a high-level programming language, so I know from first-hand experience how it is to learn on 8-bit CPUs. Nevertheless, given a choice, I would never use those again for this purpose. None of the traditional 8-bit CPUs (i.e. introduced before 1980) had many instructions that took exactly one clock cycle. Most of their instructions required multiple clock cycles with a number different for each instruction. Nevertheless, on many 8-bit CPUs you could guess approximately the number of clock cycles for many instructions based on the number of memory cycles needed for executing the instruction (including the cycles required for fetching the instruction code). On the contrary, modern 32-bit microcontrollers have a majority of instructions that are executed in one clock cycle. Regarding the cache memory, the slower models with a clock frequency below 100 MHz, e.g. from 24 to 72 MHz may have no cache, and even if they have a cache, not enabling it would not make much difference. From all that you have said I agree only with the fact that a 32-bit MCU will have usually a complex clock tree with various PLLs that must be programmed for maximum performance. Nevertheless, besides the fact that programming the PLLs is usually needed only in a single place, at startup, it is also optional for many applications. All 32-bit MCUs that I have seen start after reboot in a safe mode using an internal RC oscillator. The speed is low, but it works. You need to program the PLLs only if you want to reach the maximum speed by using an external quartz oscillator or resonator. The 32-bit MCUs may have a large number of complex internal peripherals but at least in the beginning it is possible to ignore their existence. Only the few peripherals that are used must be enabled and configured and the MCU vendors provide example programs that can be used before learning how to modify them. 8-bit disassembly does not have a lower instruction count but it always has a much higher instruction count for doing the same task, because each 8-bit instruction does less work. The easiest to program in assembly language are the 64-bit CPUs, because the range of 64-bit numbers is big enough to use them in most applications without worries. Already with 32-bit numbers you must be careful to avoid overflows, while with 16-bit or 8-bit numbers you must be prepared to handle overflow at each operation. So on CPUs with narrower hardware instructions and registers, you must almost always write or use a library implementing operations with wider numbers, which makes the programs more complex than for 32-bit CPUs, because only seldom you can do an addition or multiplication etc. by just using one hardware instruction. For the 32-bit ARM CPUs all the software tools that one may need are free. For most 8-bit CPUs the tools are either proprietary or of lower quality than for the 32-bit CPUs. There are 32-bit ARM CPUs that are soldered together with support circuits on a very small PCB with DIP pins (e.g. various models of STM32 Nucleo-32 boards), which can be inserted in DIP sockets or in solderless breadboards, so DIP is not an advantage exclusive to obsolete 8-bit CPUs. There are many such 32-bit microcontrollers that have high-current pins that can drive directly LEDs and most cheap development boards may include buffers to provide 5-V tolerant I/O pins on the headers mounted on the board. While for the cheapest 32-bit development boards the user interface must be done on some PC to which the development board is connected via USB, or the board may be used through a console on a serial interface or through a remote shell over Ethernet (for the boards including an Ethernet RJ-45 connector), there are more expensive boards, e.g. around $50, to which it is possible to connect a display panel directly. It is true that I have never used an Arduino, because every time when I looked at any model it appeared overpriced and without any advantage whatsoever over a Cortex-M board, so I could not understand why would someone waste time with it. On the other hand, the costs of learning to program a development board with Cortex-M are close to zero and the experience is much more valuable.
  - klelatti 3y ago
    This isn’t what the comment I replied to was suggesting. Also, I can see there is a case for using a simple modern design such as Cortex-M as a base but - as the peer comment also says - it’s really not the case that a Cortex M7 is conceptually simpler than a 8-bit design.
    - adrian_b 3y ago
      Programming in assembly language a Cortex-M7 for doing any non-trivial task is much easier than writing an equivalent program for a Zilog Z80 or a MOS Technology 6502 or any other classic 8-bit CPU. For most operations that can be done in one machine instruction on a 32-bit CPU like Cortex-M7 (which also includes support for floating-point numbers), you need to write a complex sequence of instructions for 8-bit CPUs like Z80, 6502 and the like, where you do not have even a multiplication instruction, much less more complex operations. To be able to write performant programs on ancient 8-bit CPUs requires much more knowledge and experience than on modern 32-bit CPUs, because you need to implement in software many algorithms for things that are done in hardware on the modern CPUs.
      - klelatti 3y ago
        > To be able to write performant programs Wait we’re teaching kids to write performant assembly language?
        BlueTemplar 3y ago
        Yeah, there's another thing that is bugging me a bit about all this... 8-bit basically means ASCII when you deal with text (doesn't it ?) - how do you teach middle-schoolers that don't use a latin-based alphabet in their native tongue ??
        tayo42 3y ago
        Doesn't 8 bit of just mean the size of the possible address space. When you encode something more complex then ascii you use 1-4 consecutive bytes, the encoding in the byte tells you if you need to look at the next.
  - ByQuyzzy 3y ago
    [dead]

klelatti 3y ago

Are you suggesting that 'Deep OS knowledge', syscalls, C, assembly, packets and networking protocols should be taught in schools? What I think the author is getting at with '8-bit' is that presenting children with a complete machine that is simple enough to understand from top to bottom gives a foundation that they can build on when they encounter more complex systems later on.

adrian_b 3y ago
The 32-bit ARMv7-M micro-controllers with Cortex-M4 or Cortex-M7 cores that are available for instance on $10 development boards from ST or from many other companies are conceptually simpler and easier to understand when programmed at the bare-metal level than the 8-bit computers of 40 to 50 years ago. They are a much better target for teaching children about hardware.
- FirmwareBurner 3y ago
  Hard disagree. 8 bit micros are far simpler to understand from every perspective and depth than the 32 bit micros. One of the main benefits of teaching on 8 bit micros is they function like basic HW Harvard state machines, meaning their code execution is easily predictable and explainable form the diagrams on paper/whitrebaord, to the disassembly in the debugger in practice, as every CPU instruction takes exactly one clock cycle, there's no memory caching, no PLL and various multipliers and dividers for the 50 on-chip clock domains and IRQ tables, but they have on single clock from an external oscillator from which the CPU, RAM and FLASH memory, and all peripherals run on only that clock meaning it's easier to draw clock/signal diagrams to show "on this rising edge the CPU fetches the instruction, on the next clock edge, the ADC triggers the sampling, etc" Secondly, 8 bit micros come in DIP packages easier to breadboard and are 5V tolerant meaning you can just hook them up to USB, and most of the times they have high current pins with Schottky diodes meaning you can have them rectify AC voltage or direct drive LEDs without transistors. Thirdly, IMHO, 8bit ASM disassembly, like the Atmega AVR, is much easier to follow and understand in the debugger for beginners than the 32 bit ARM due to lower instruction count and simpler less powerful instructions that are always 8 bit, and less features that can confuse you like configurable IRQ tables or powerful instructions that cand do two operations at once per clock cycle for extra performance or optimized instructions that are 16 bit instead of 32 bit to save code space like the ARM Thumb. 8bit micros like the old Arduinos are far ore capable for learning and hobbyist tinkering than people give them credit for. People just needlessly fixate against them because "32 bit is bigger than 8 bit". My $0.02.
  - spease 3y ago
    > If you wanna play with 32 bit machines to understand how they work you can just build and debug 32 bit code on your x86_64 machine, no need to go embedded. That’s like comparing a sand castle to a hospital complex. You might want some intermediate steps in between.
    - FirmwareBurner 3y ago
      Indeed, that was a dumb statement on my part. Edited.
  - adrian_b 3y ago
    I have begun learning about computer hardware many years ago on computers with 8-bit Intel 8080, Zilog Z80 and Motorola MC6809 CPUs and I was among those who could read hexadecimal Z80 machine instruction codes as easily as a source text in a high-level programming language, so I know from first-hand experience how it is to learn on 8-bit CPUs. Nevertheless, given a choice, I would never use those again for this purpose. None of the traditional 8-bit CPUs (i.e. introduced before 1980) had many instructions that took exactly one clock cycle. Most of their instructions required multiple clock cycles with a number different for each instruction. Nevertheless, on many 8-bit CPUs you could guess approximately the number of clock cycles for many instructions based on the number of memory cycles needed for executing the instruction (including the cycles required for fetching the instruction code). On the contrary, modern 32-bit microcontrollers have a majority of instructions that are executed in one clock cycle. Regarding the cache memory, the slower models with a clock frequency below 100 MHz, e.g. from 24 to 72 MHz may have no cache, and even if they have a cache, not enabling it would not make much difference. From all that you have said I agree only with the fact that a 32-bit MCU will have usually a complex clock tree with various PLLs that must be programmed for maximum performance. Nevertheless, besides the fact that programming the PLLs is usually needed only in a single place, at startup, it is also optional for many applications. All 32-bit MCUs that I have seen start after reboot in a safe mode using an internal RC oscillator. The speed is low, but it works. You need to program the PLLs only if you want to reach the maximum speed by using an external quartz oscillator or resonator. The 32-bit MCUs may have a large number of complex internal peripherals but at least in the beginning it is possible to ignore their existence. Only the few peripherals that are used must be enabled and configured and the MCU vendors provide example programs that can be used before learning how to modify them. 8-bit disassembly does not have a lower instruction count but it always has a much higher instruction count for doing the same task, because each 8-bit instruction does less work. The easiest to program in assembly language are the 64-bit CPUs, because the range of 64-bit numbers is big enough to use them in most applications without worries. Already with 32-bit numbers you must be careful to avoid overflows, while with 16-bit or 8-bit numbers you must be prepared to handle overflow at each operation. So on CPUs with narrower hardware instructions and registers, you must almost always write or use a library implementing operations with wider numbers, which makes the programs more complex than for 32-bit CPUs, because only seldom you can do an addition or multiplication etc. by just using one hardware instruction. For the 32-bit ARM CPUs all the software tools that one may need are free. For most 8-bit CPUs the tools are either proprietary or of lower quality than for the 32-bit CPUs. There are 32-bit ARM CPUs that are soldered together with support circuits on a very small PCB with DIP pins (e.g. various models of STM32 Nucleo-32 boards), which can be inserted in DIP sockets or in solderless breadboards, so DIP is not an advantage exclusive to obsolete 8-bit CPUs. There are many such 32-bit microcontrollers that have high-current pins that can drive directly LEDs and most cheap development boards may include buffers to provide 5-V tolerant I/O pins on the headers mounted on the board. While for the cheapest 32-bit development boards the user interface must be done on some PC to which the development board is connected via USB, or the board may be used through a console on a serial interface or through a remote shell over Ethernet (for the boards including an Ethernet RJ-45 connector), there are more expensive boards, e.g. around $50, to which it is possible to connect a display panel directly. It is true that I have never used an Arduino, because every time when I looked at any model it appeared overpriced and without any advantage whatsoever over a Cortex-M board, so I could not understand why would someone waste time with it. On the other hand, the costs of learning to program a development board with Cortex-M are close to zero and the experience is much more valuable.
- klelatti 3y ago
  This isn’t what the comment I replied to was suggesting. Also, I can see there is a case for using a simple modern design such as Cortex-M as a base but - as the peer comment also says - it’s really not the case that a Cortex M7 is conceptually simpler than a 8-bit design.
  - adrian_b 3y ago
    Programming in assembly language a Cortex-M7 for doing any non-trivial task is much easier than writing an equivalent program for a Zilog Z80 or a MOS Technology 6502 or any other classic 8-bit CPU. For most operations that can be done in one machine instruction on a 32-bit CPU like Cortex-M7 (which also includes support for floating-point numbers), you need to write a complex sequence of instructions for 8-bit CPUs like Z80, 6502 and the like, where you do not have even a multiplication instruction, much less more complex operations. To be able to write performant programs on ancient 8-bit CPUs requires much more knowledge and experience than on modern 32-bit CPUs, because you need to implement in software many algorithms for things that are done in hardware on the modern CPUs.
    - klelatti 3y ago
      > To be able to write performant programs Wait we’re teaching kids to write performant assembly language?
      - BlueTemplar 3y ago
        Yeah, there's another thing that is bugging me a bit about all this... 8-bit basically means ASCII when you deal with text (doesn't it ?) - how do you teach middle-schoolers that don't use a latin-based alphabet in their native tongue ??
        tayo42 3y ago
        Doesn't 8 bit of just mean the size of the possible address space. When you encode something more complex then ascii you use 1-4 consecutive bytes, the encoding in the byte tells you if you need to look at the next.
- ByQuyzzy 3y ago
  [dead]