The art of programming is not the manipulation of a programming language or machine code. It's the symbolic relationship of data and function to input and output. There are really only two equivalent programming models today, Lambda calculus and Turing_machines (with their architectures).

Any large assembly programming project becomes a high level language project as you must define data, expression and symbolic interfaces at a level higher than machine code so a person who develops non trivial assembly projects De facto creates their own HLL standard that in the end is usually not that much different from C, Basic or other common languages.

 

The art of programming is not the manipulation of a programming language or machine code. It's the symbolic relationship of data and function to input and output. There are really only two equivalent programming models today, Lambda calculus and Turing_machines (with their architectures).

Any large assembly programming project becomes a high level language project as you must define data, expression and symbolic interfaces at a level higher than machine code so a person who develops non trivial assembly projects De facto creates their own HLL standard that in the end that's usually not that much different from C, Basic or other common languages.

We're on the same page. I personally think that the bottom line reads "experience". Unfortunately, when one reaches that milestone, it's usually one among many pointing to how old wed really are.

 

The art of programming is not the manipulation of a programming language or machine code. It's the symbolic relationship of data and function to input and output. There are really only two equivalent programming models today, Lambda calculus and Turing_machines (with their architectures).

Any large assembly programming project becomes a high level language project as you must define data, expression and symbolic interfaces at a level higher than machine code so a person who develops non trivial assembly projects De facto creates their own HLL standard that in the end is usually not that much different from C, Basic or other common languages.

I resent that you are calling my .asm a HLL!

Yes, I use macros to speed my coding -- and to make it more manageable and readable -- but the macros only expand to a fixed set of .asm mnemonics. There is no interpretation of my intentions as there are in a HLL like C.

A simple HLL concept like:

IF (general expression) THEN (general expression) ELSE (general expression)

has no parallel in .asm (except in the simplest terms). In fact, there is nothing like a general expression in .asm.

Because HLLs like C must interpret such things -- for all possible cases, and, hopefully, in the way the programmer intended -- the compiled code will never be as fast or compact as .asm.

I would never write .asm for, say, an x86 or an ARM. But for small, cheap, MCUs -- with limited RAM and ROM and no software stack -- I won't use anything else.

 

I would never write .asm for, say, an x86...

I did, back in the days of the 80286. Thankfully, though, I don't wake up screaming in the middle of the night anymore since the nightmares stopped a couple of years ago.

But for small, cheap, MCUs -- with limited RAM and ROM and no software stack -- I won't use anything else.

Lately I've mostly been working with the dsPIC30F and dsPIC33E chips. Contrary to what you might expect, I'm finding that these things are really, REALLY easy to work with in .asm-- much easier than the PIC18F or PIC16F devices.

 

I would never write .asm for, say, an x86 or an ARM.

I'm so glad you brought that up. I've been thinking about migrating from the 8051 and start learning a new architecture that works in either 16 or 32 bits... ARM was one of the candidates... but now, after seeing how you feel about .asm for ARM, I'm going to have to look for something a little less challenging. What would you suggest?

I'm finding that these things are really, REALLY easy to work with in .asm

What's the max speed in instructions per second for those chips? Do they work in 16 or 32 bits?

the nightmares stopped a couple of years ago.

My first nightmares involved the stupid way in which the Apple II (which ran using interpreted BASIC) managed its memory around variable arrays... an idiotic memory clean instruction (which took ages to complete) had to be performed every once in a while or the piece of junk would crash...

 

I'm so glad you brought that up. I've been thinking about migrating from 8051 and start learning a new architecture that works in either 16 or 32 bits... ARM was one of the candidates... but now, after seeing how you feel about .asm for ARM, I'm going to have to look for something a little less challenging. What would you suggest?

No comment. I used ARM as an example, not a platform...

My first nightmares involved the stupid way in which the Apple II (which ran using interpreted BASIC) managed its memory around variable arrays... an idiotic memory clean instruction (which took ages to complete) had to be performed every once in a while or the piece of junk would crash...

Not idiotic at all. These old computers had extremely limited memory. Dynamically sized data (i.e. strings and arrays) would be created in a "pool" -- a fixed-size portion of memory set aside for such data. A new element would be created in the first available free space that was large enough to contain it. Deleting that element would just remove a pointer to that location. Eventually, there are no more gaps large enough to house new data, so a cleanup routine would execute to move all the live data and free up a larger contiguous block -- thus causing a delay.

The alternative would have been for your code to crash with an out-of-memory error.

 

What's the max speed in instructions per second for those chips? Do they work in 16 or 32 bits?

The dsPIC series are all 16-bit. They have sixteen 16-bit working registers, one of which is the stack pointer; a large, linear address space; a huge instruction set, with most instructions able to operate on any register or combination of registers; lots of addressing modes when using registers to hold pointers; hardware multiply and divide; a "proper" set of branches on specific conditions; and the DSP MAC engine is available (and very handy) for ordinary program use. The dsPIC30F parts are 3V/5V and top out at 30 MIPS and the dsPIC33EP parts are 3 volt only and 70 MIPS.

My first nightmares involved the stupid way in which the Apple II (which ran using interpreted BASIC) managed its memory around variable arrays... an idiotic memory clean instruction (which took ages to complete) had to be performed every once in a while or the piece of junk would crash...

Ah yes... the hated "garbage collection" that the Apple II would run every now and then, without warning!! I remember it well...

 

The alternative would have been for your code to crash with an out-of-memory error.

And that's the alternative that kept on happening again and again until I found about that memory issue, and the instruction to free it. I never took a programming course for the Apple II, but learned it by just reading the manual and looking at the instruction set. It wasn't until I read the instruction set carefully that I discovered what was wrong.
You're right... I sometimes fall into the trap of judging old technology with modern standards. The Apple II was a marvel in its own right at the time.

 

And that's the alternative that kept on happening again and again until I found about that memory issue, and the instruction to free it. I never took a programming course for the Apple II, but learned it by just reading the manual and looking at the instruction set. It wasn't until I read the instruction set carefully that I discovered what was wrong.
You're right... I sometimes fall into the trap of judging old technology with modern standards. The Apple II was a marvel in its own right at the time.

Oh! I didn't realize you had to do it manually on the Apple. The TRS-80 did it automatically.

 

I resent that you are calling my .asm a HLL!

“even the best compilers are still no match for the best humans, given infinite time and ingenuity.”

 

Oh! I didn't realize you had to do it manually on the Apple. The TRS-80 did it automatically.

Even before I laid my hands on an Apple II, I learned programming on a Timex Sinclair ZX81. It had a membrane type of keyboard, and stored its programs in a cassette recorder... can't recall if it had the same memory problem (issue, restriction?) as the Apple II, though... God, what a memory!

 

Even before I laid my hands on an Apple II, I learned programming on a Timex Sinclair ZX81. It had a membrane type of keyboard, and stored its programs in a cassette recorder... can't recall if it had the same memory problem (issue, restriction?) as the Apple II, though... God, what a memory!

I built the kit form of the ZX80.

 

Yup... my setup looked very similar to this:

​

 

I once made my own simple PLC from the Motorola 1 bit processor, MC14500B.
Teaches you Boolean also.
https://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/
Max.

 

OMG I forgot all about using cassette recorders to store programs and data...

I still have my copy of the very first issue of Byte magazine (September 1975), with an article titled, "Cassette Interface-- Your Key to Inexpensive Bulk Memory." Plus articles on writing your own MC6800 assembler, reclaiming used ICs, deciphering surplus keyboards, and chock full of ads for such gems as the Altair 8800, the Scelbi 8B, and the RGS 008A kit featuring the Intel 8008.

Good times!

 

OMG I forgot all about using cassette recorders to store programs and data...

I still have my copy of the very first issue of Byte magazine (September 1975), with an article titled, "Cassette Interface-- Your Key to Inexpensive Bulk Memory." Plus articles on writing your own MC6800 assembler, reclaiming used ICs, deciphering surplus keyboards, and chock full of ads for such gems as the Altair 8800, the Scelbi 8B, and the RGS 008A kit featuring the Intel 8008.

Good times!

I love going through the old stuff. It's all available online. My favorites are Elementary Electronics, Radio Electronics, and 80 Microcomputing. The ads are a fantastic trip down memory lane!

 

Most of the stuff I did back then (8080, 8085, Z80) was 44 pin bus.
Z80

8080 with memory and boot ROM card

Wire-wrap backside.

I might just use an old processor to make a retro clock one day, plenty of space left over a SPI display and even use my old Assembly language book to do it.

 

Most of the stuff I did back then (8080, 8085, Z80) was 44 pin bus.
Z80

Do they still work? For old times sake, I want to build a Z80 computer to run Rogue on CP/M . I play with CP/M on an emulator, but there is nothing like real iron.

 

My first real assembly language (excluding simulators in college.)

 

My first real assembly language (excluding simulators in college.)
View attachment 93309

I still have mine -- along with this: