Learn Programming from Machine Level Up

Go To Last Post
33 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few years ago, I entertained the idea of a magazine article on “Retro-Computing with Tiny BASIC”.  I used ATMEL Studio and the ATmega1280 for the project.  In time, I rethought the whole idea and began to develop a more comprehensive treatment, one that would introduce programming beginning with machine language and moving upwards to a high-level language like BASIC.  The idea is depicted in the graphic below.  I also decided that a magazine article was not an appropriate vehicle for what I had in mind.  Nor would a book do, as I wanted to make it possible to experiment with machine language.  In the end, I created a website with an Altair 8800 like front panel emulator and a series of experiments.  The experimenter learns the inner workings of the Intel 8080, first by flipping switches then using an assembler and finally by working with a high-level language, Tiny BASIC.  The experimenter continues to explore modern programming with ATMEL Studio using the ATmega328 and ATmega1280.  A customizable, open source AVR Tiny BASIC makes possible the creation of  specialized statements and functions to control and access every capability of the ATmega328/1280.  I am interested in whether this approach to introducing programming has merit and if there are ways to improve it.  The website is www.whippleway.com.

Programming Levels

Last Edited: Tue. Sep 5, 2017 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe that this would have been a good idea 40 years ago.  AVRs weren't around then, but simple CPUs like the 8080, the 6502, and 6800 were.

 

For modern times, I would skip the Hardware, Machine Language, and Assembler stages.  And I would go lightly on the Java, FORTRAN, BASIC, and other high-level languages.  Concentrate on using pre-written/tested libraries available for C++ and your CPU.

 

We are entering the era where the functional application is the main goal of programming, and not the internal workings of an individual processor.

 

I learned CPUs from the ground up: starting in high-school with vacuum tubes (with their 300+VDC operation levels), going on the transistor biasing, then digital TTL logic, then microprocessors (which were $15-$25 each at the time).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta beat me to it, as I was about to say the same thing, as I too learned it that way so long ago using a M6800. 

Assembly is nice to know, but for the HLL, C or C++ and the Arduino environment is readily available and cheap.  

 

Good luck with the project,

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

I would teach diodes then transistors then simple gates then flip-flops then half adders then full adders then banks of 8 or 16 of these then ALUs then latches then databusses then RAM then ROM then CPU then MCU then microcode then instruction decoders and so on up to the starting point above. You simply cannot know enough about the electronics you are programming! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Listen to Kate Gregory.

She's a very smart girl.

Extremely smart that is.

 

https://www.youtube.com/watch?v=...

 

In the (1 hour long) video above she explains very clearly to teachers why they should not start by teaching C to students if the goal is to learn C++.

Very extremely short: Why teach such out dated (Exept for specialized "advanced" cases) concepts as "pointers" when you want to use references, and a lot of other good reasos.

Learning a printf( "Hello world.\n"); on day one which they have to unlearn at day 3.

She gives a lot of very good reasons why C++ is perceived as "difficult" while in fact it isn't. It is mostly the transistion from (old habits) in C to (effective) programming in C++ which make it seem difficult.

 

What you want to teach is nog "programming" but "computer architecture", which is quite different.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I both agree and disagree. 

 

Yes, I would quit teaching about gates, ALUs, and such. I would ignore flip-flops as cells of registers and SRAM. I would ignore assembly language (for the most part).

 

BUT, at least in the microcontroller universe, you NEED to know about UARTS, timers, ADCs, I2C, SPI, and that lot. That stuff is still called HARDWARE. No software abstractions, no interface layers or libraries, no high level language, none of that stuff can hide the fact of how PWM works or the consequences of major noise in an async serial data stream (think crap wireless modules). Or, things like the fact that peripherals are clocked, and if you turn the clock off, they stop operating! You need to know that (most) ADCs have a sample/hold at the input and that s/h has consequences. There are so many more details that they really can't be listed here, and many depend on the implementation of the specific MCU (but, YOU need to know that such details ARE there and that you need to look for them before you start).

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Sep 5, 2017 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the excellent observations.  Looking back to my original posting, I think my couching it as "introduce programming" was not accurate.  What I really meant to suggest was that my website is intended to acquaint folks with microprocessors.  Knowing something about their inner workings is interesting and can be helpful to experienced programmers when performance issues arise or when access to specialized hardware capabilities is limited.  It was not my intention to teach programming though I may have left that as an impression before.  

 

So far, I have avoided hardware details, just focusing on the functionality of the various microcomputer components.  I didn't want to frighten off non-electronic folks.  I was inspired by Noam Nisan and Shimon Schocken with their book "The Elements of Computing Systems" and their great http://nand2tetris.org/ website.  They present computer hardware in a way that appeals to both technical and non-technical types.  The only electronics you might want to know is the NAND gate.  From there, you build a functioning computer.  I suppose what I am trying to do is present low level software in a similar way and, by doing so, "unbox" the functional components of the microprocessor.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It feels like the concept of 'from first principles' is sorely lacking these days.  I applaud any effort to remedy that.

 

However, I agree that from a pedagogical point of view, there is little value in this bottom-up approach to education.  Mostly, that's because (IMO) education is badly broken.  It is designed to crank out workers, rather than to truly edify and educate.  Knowing which eBay vendors from which to source your $2 MP3 player boards does not constitute an education.  I'll stop there, lest I start a war ;-)

 

Lovely site.  Carry on!

 

EDIT:  I only just now visited http://nand2tetris.org/ ... and I see that Nisan and Schocken agree with me: "Building a Modern Computer from First Principles" ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Sep 6, 2017 - 02:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
pedagogical

 

Had to look that up....

 

In case others are wondering:

https://www.merriam-webster.com/...

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would skip the Hardware, Machine Language, and Assembler stages.

 I don't know.  From what I've seen, the failure to have even a basic understanding of "Hardware" is one of the big stumbling blocks between "programmer" and "embedded programmer."  But I'm not sure what form "basic understanding" should take.  :-(   I'd have said that you could skip machine language (unless the assembler is significantly non-parallel, ala x86), except I've seen people try to load C code into their flash, with no concept of what a compiler does, what an assembler does, or how binary code is different from source code.  When we old-timers say "you can forget about xxx", we're not remembering that our understanding of the core concepts of "xxx" is so ingrained that it lends us an important degree of understanding to higher level concepts.  Ever met anyone who never learned about different number bases?  I have.  New programmers today don't need to memorize their 8080 octal opcodes, but they need ... something.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When looking at a micro port I can only see 8 D-type latches and understand the FETs/transistors being used to achieve that with current limits etc., same with RAM 8 latches per byte, I can see the electrons flowing inside the chip.

 

I can see the protection diodes inside the port when used as input, I can see the gates making up the oscillator, data being shifted around between register (again 8 latches per register) and ports or RAM.

 

hmmm I must be crazy.....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

No John, you are not crazy. Same symptoms here. Or, maybe that makes two crazies? Cannot be!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the occasion that I teach anyone about computers, I start with a very quick overview of the base-ten number system.  How it is ten symbols and how if one needs to go higher than ten in count, the next higher numbers are the same set of symbols moved one place to the left.  Then I branch/segue to base-two, and how each left-ward place is two times the place to the right: 2x2x2x2x2x2 = 64.  Then it's to electricity: wires, batteries, and integrated circuits. How the IC has only two electric levels on each pin: the battery voltage or no voltage, and that the only things that the pins do on a chip is present either one or the other of the electrical levels.

 

  Then comes the deep stuff:  how any number can be transferred over a single wire pair by placing the base-two representation on the wire one bit at a time in order.   Then how any color can be made from 256 brightness levels of red:green:blue if the color is being made by a device with an internal light source.  And how the three values can be sent over a single wire between the IC and the LED.  Then I show a NeoPixel rotating through its color sequence, along with an oscilloscope display of the changing Vcc/gnd signals that are facilitating the color changes.  Then I show a TFT display and explain how its image is created from a grid of 240x320 pixels, each one having three color values.

 

  If time and interest persists, I explain how sound is movement of air.  How this movement can be recorded and reproduced by breaking each time second into 44,100 stages, and how the intensity of sound can be converted into a sequence of numbers; each one a unique level on a scale of 65536.

I end the first lesson with an explanation of how a hundred individual telephone conversations can be sent simultaneously over a single wire by using this method of pulse-code-modulation.

 

  I end by remarking that they now know more about how computers and electronics work than 999 out 1000 public-school teachers, and 9999 out 10000 ordinary people. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Somewhere buried in a box is my copy of Carl Boyer's book on "The History of Calculus and Its Conceptual Development".  I had to read it at university.  A point he made that has stuck with me is that one way to become truly proficient in a field of study is to walk in the steps of the field's developers.  What took them perhaps decades to work out, a properly designed treatise can lead the reader through in a few hours read.  That's not exactly how he put it, but rather how I remember it.  When the Altair 8800 arrived on my doorstep in 1975 with only 256 bytes of memory, no languages whatever, and only an Intel 8080 spec sheet, I had no choice but to follow a "start from scratch" path.  The latter approach has served me well as general and embedded programmer.   I would never wish on anyone the trials and tribulations I went through.  The website is merely my attempt to follow Boyer's dictum, as it embodies my conceptual development from machine to high-level language.  If it leads some to proficiency beyond what they have already achieved, then fantastic!  

Last Edited: Thu. Sep 7, 2017 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I first studied Calculus in high school, grade 12, what would be called my senior year in the US.  It was my calculus teacher, a wonderful Scotsman named Mr. Stuart, who first introduced me to the concept of 'first principles'.  He took our class along the very journey you describe when he taught us about derivatives.  I have to say it was of incalculable value to me.  I can't say if it was for any of the other students.  For me though it was a Eureka moment.  When the light bulb went on, I understood not only the foundational math underpinning Calculus, but also the power of learning from first principles.  I have never forgotten it.  I can still hear Mr Stuart's brogue, "dee-wye ohvahr dee-axe..."

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Sep 7, 2017 - 05:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it was of incalculable value to me

So you failed Calculus?? surprise

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Puns are to be offered and abandoned in one swell foop ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Sep 7, 2017 - 11:38 PM