I worked on IBM mainframes in the early 80s, although I never coded for that machine in assembler I did carry one of these around given to me by an older programmer, the 360 instruction set reference card.

 

I coded on S/360 and later IBM mainframes in assembler. I used to read machine code from ore dumps just as easily as reading the assembly language. For lesser used instructions the reference card was needed, best job I had was reading core dumps for others, working out what was wrong and what to do to fix it and pass the info back to them for them to fix. Most dumps were application issues so quite easy, larger system issues took a lot longer to work out in particular when instructions had been overwritten.

 

I have the following eclectic collection of reference cards in no particular order

1. RCA CDP-1802
2. Signetics SC68000
3. Intel 8080/8085 Assembly Language Reference Card
4. Motorola MC68HC05Cx Programming Reference Guide
5. Intel MCS-4 Reference Card
6. Motorola MC68HC11A8 Programming Reference Guide
7. Zilog Z8 Program Reference Guide (December 1979)
8. Intel MCS-48 Assembly Language Reference Card
9. Intel 8080 Assembly Language Reference Card (January 1975)
10. Metalink (,,,the ICE HOUSE) 8051 Family Pocket Reference Guide
11. Intel MCS-51 Macro Assembly Language Pocket Reference Guide
12. Intel UPI-41A Assembly Language Reference Card
13. Microsystems CP/M Programmer's Reference Guide
14. Digital Equipment Corp. PDP-11 Programming Card (1972)
15. Intel ICE-41A In-Circuit Emulator Pocket Reference
16. Intel MCS-8 Micro Computer Set (1972)
17. Synertek SY6500 Instruction Set Summary
18. MOS Technology MCS6500 Instruction Set Summary
19. Olivetti Sistema Audit 7 Tavola Di Riferimento (lit. Card of Reference)
20. Motorola MC6809 Instruction Set Summary
21. Omnibyte MC68000 Microprocessor Programming Card
22. Mostek Z80 Micro Reference Manual
23. Olivetti DE525 Reference Card
24. MOS Technology MCS650X Instruction Set Summary
25. Zilog Z-80 CPU Programming Reference Card

 

I coded on S/360 and later IBM mainframes in assembler. I used to read machine code from ore dumps just as easily as reading the assembly language. For lesser used instructions the reference card was needed, best job I had was reading core dumps for others, working out what was wrong and what to do to fix it and pass the info back to them for them to fix. Most dumps were application issues so quite easy, larger system issues took a lot longer to work out in particular when instructions had been overwritten.

I worked with IBM mainframe PL/I a great deal and it was "normal" to sometimes walk into the office and find a dump listing (fan fold paper) sitting on my desk. The crash dump from a PL/I program was very structured - if one knew the layout of the many 'control blocks'.

I could look at those dumps and often discern a lot (these were blocks of memory, linked by pointers and containing data, like stack frames and so on) because one became used to the structure. Although code blocks were also present these were never relevant much, it was stuff like "so what was in that string arg" and "what as in array element x,y?" and what were the args passed into the caller of the call that called the crashed procedure" etc.

Lots of fun. Programming back then involved a lot more technical stuff than it does today.

 

I worked with IBM mainframe PL/I.....

PL/1 was a really lovely language. I ran across it late in the day and it fit me like a glove, best of all the languages I had used.

 

PL/1 was a really lovely language. I ran across it late in the day and it fit me like a glove, best of all the languages I had used.

It's a very notable language, it was used to write the Multics OS and later Stratus' VOS. In fact it was the first high level language used to write an OS. As a systems programming language it had features still lacking today in C, C++ etc. It was the first language to have pointers and exceptions for example.

IBM PL/I though was huge, very hard to implement compilers for by other vendors, that changed when Subset G was standardized, but by then C had gotten traction so PL/I struggled to gain popularity.

Modern imperative languages are more and more reliant on stuff like generics, garbage collection, lambda functions etc, so PL/I appears weak, but in reality could readily compete with C in embedded and OS oriented domains.

 

My mainframes were the IBM 7090/7094 and S/360 using FORTRAN and SNOBOL (ca. 1962-1969)

 

My mainframes were the IBM 7090/7094 and S/360 using FORTRAN and SNOBOL (ca. 1962-1969)

That's computer history right there!

 

I've never used assembly myself but I learnt about it when learning compilers. My understanding is assembly is a very low level programming language. It's meant to offer direct access to memory registers and allow full control where a compiler might prevent or limit an operation.

On the other hand, a compiler is quick and generally very efficient at generating machine code. While it's true an operation may run faster in assembly, it's up the programmer to write the entire algorithm and all the sub-routines that normally come ready with something like C or C++.

Unless you have experience writing mathematical algorithms, C++ will do everything you probably need and better than if you wrote the program in assembly. For most things, it seems like a really slow and error prone way to write software. I'd be interested to hear from people who had their careers in assembly like languages.

I started on Z-80 & 6809 CPUs using BASIC to just get used to things. Almost all the projects I did across 40 years were on microcontrollers in assembler. Cost & size were important but speed was the usual motive. Compilers are required in certain structures that pure assembler can violate. In a compiler, an interrupt Must save all registers, BUT assembler can save only the relevant ones. You can also do "questionable" behaviors like, purging the stack (toss all original values) and exit to a completely different place. This is Very Handy for error routines, BUT you can get in Real Trouble as well.
Assembler also teaches you the value of GOOD Documentation & Commenting. Return to code you need to tweak after a year on other stuff and see how long it takes to understand what you did back then!