Learning Assembly and computer architecture for x86

[elias001]

@sbrothy thank you again.

 

[Mark44]

I still feel weird about and uneasy about learning a programming language only for a specific architecture then knowing that on a different architecture the same programming language will have differences.

You are mistaken here. Different architectures have different assembly languages. Sometimes there even are different versions of an assembly language for a given processor when different OSes are being used, for example with Windows vs. Linux. That said, once you become competent with one assembly language, it's not that difficult to learn how another one does things.

 

[FactChecker]

That said, once you become competent with one assembly language, it's not that difficult to learn how another one does things.

I think the difference between RISK versus CISK is more significant than that.

 

[FactChecker]

I still feel weird about and uneasy about learning a programming language only for a specific architecture then knowing that on a different architecture the same programming language will have differences.

To be more precise, an assembly language is matched to the architecture that it runs on. Different architecture has a different assembly language.
The higher level languages have standard versions that should run properly on any compliant machine.

 

[sbrothy]

Which is also why I’m a little surprised that @elias001 chose to start at assembler level and not, say, C, which is what I did. But to each his own.

 

[Mark44]

I think the difference between RISK versus CISK is more significant than that.

RISC (reduced instruction set computing) instruction sets are smaller than those for CISC (complex instruction set computing), which is fairly obvious if you unpack the acronyms. For a given processor you have registers and memory, and the instruction set provides operators to load into or store out of registers into memory or other registers, to perform arithmetic operations on values in the registers, to branch to other parts of the program, and so forth.
I've written code in Intel x86 and x64 assembly (CISC) as well as MIPS and ARM (both RISC). Although CISC instruction sets have way more instructions, a lot of the time the instructions one uses are more-or-less common to both types of computing.

 

[Mark44]

Which is also why I’m a little surprised that @elias001 chose to start at assembler level and not, say, C, which is what I did. But to each his own.

I think he said somewhere along the line, that he had done some programming in C or C++.

 

[sbrothy]

I think he said somewhere along the line, that he had done some programming in C or C++.

Ah.

 

[elias001]

@sbrothy I went through C, and now am going through the book Introduction to computing systems from bits & gates to C/C++ & beyond. When i first said I was going through this book, it forgot to put down the first part since the second part of the title was much more memorable and easier to remember for me. Anyways, the book has the Lc3 mini assembly language. As you know and I soon found out the x86 family of architecture, there is no online emulator/simulator and the more i looked around, the more confusing and the more questions I ended up having. Also, some of those old assembly language books had sections on how to sort stuff. Though none of them discusses data structures in full that one would find in a C book

 

[FactChecker]

Although CISC instruction sets have way more instructions, a lot of the time the instructions one uses are more-or-less common to both types of computing.

I got the (maybe incorrect) impression that RISC programming was harder when there was a great shortage of RISK programmers. Maybe the shortage was due to the initial flood of RISK processors rather than their programming difficulty. I thought that RISK processing was like low-level array processor programming, where you had to keep track of the short time that the output of every operation was available and grab it in that cycle. That was like 3-dimensional assembler language programming.

 

[Mark44]

I thought that RISK processing was like low-level array processor programming, where you had to keep track of the short time that the output of every operation was available and grab it in that cycle.

No, nothing like that. You don't have to keep track of time. That sounds more like low-level real-time programming, as a guess. I don't have any experience doing that sort of programming.

 

[nsaspook]

@sbrothy, @Rive and @FactChecker I think all three of you recommended me to try out microcontrollers/embedded systems. So say I wrong an assembly program to control some tiny devices. Is that finished program call "firmware"?

Also the two advanced assembly language books that i have are:

Advanced Assembly Language on the IBM PC by Steven Holzner

and

Advanced Assembly Language by Allen L Wyatt

The two C books with assembly programming are:

C with Assembly Language by Steven Holzner

and

X86 Assembly Language and C fundamentals by Joseph J F Cavanagh.

I do also have that Peter Norton's book.


If I have any other questions about this topic, I will ask in a new post. I appreciate all of you explaining assembly language to me. I still feel weird about and uneasy about learning a programming language only for a specific architecture then knowing that on a different architecture the same programming language will have differences.

I also think you should look a micro-controllers/embedded systems to gain experience with ASM programming and embedded system design. Embedded systems are much more than low-level programming. IMO spending a lot of time and energy on assembly language for complete programs is a waste of resources for most people in the field. You effectively need to create your own HLL to program larger programs with ASM so it's usually better to use an HLL like C that allows easy integration with ASM for hardware specific functionality.

My current home project requires PIC18 firmware for a board I designed with just a little ASM for things you can't do in C. The PIC assembly is simple and direct.
https://github.com/nsaspook/mqtt_comedi/tree/fixes/bmc
Reading PIC18 device registers in main.c

device_id_data_t DeviceID_Read(device_id_address_t address)
{
    device_id_data_t deviceID;

    //Save the table pointer
    uint32_t tablePointer = ((uint32_t) TBLPTRU << 16) | ((uint32_t) TBLPTRH << 8) | ((uint32_t) TBLPTRL);

    //Load table pointer with Device ID address
    TBLPTRU = (uint8_t) (address >> 16);
    TBLPTRH = (uint8_t) (address >> 8);
    TBLPTRL = (uint8_t) address;

    //Execute table read and increment table pointer
    asm("TBLRD*+");

    deviceID = (device_id_data_t) TABLAT;

    //Execute table read
    asm("TBLRD*");

    deviceID |= (device_id_data_t) (TABLAT << 8);

    //Restore the table pointer
    TBLPTRU = (uint8_t) (tablePointer >> 16);
    TBLPTRH = (uint8_t) (tablePointer >> 8);
    TBLPTRL = (uint8_t) tablePointer;

    return deviceID;
}

This PIC device talks with a Linux system using a kernel protocol driver module that talks to a Orange Pi via SPI.

Driver daq_bmc
https://github.com/nsaspook/mqtt_comedi/blob/fixes/daq_bmc/daq_bmc.c

 spibmc spi1.1: spi link version 1.3
[    7.345168] spibmc spi1.1: BMCboard default: do_conf=1, di_conf=1, daqbmc_conf=0
[    7.346479] comedi comedi0: bmc protocol version 0.96
[    7.346502] comedi comedi0: 4 cpu(s) online for threads
[    7.346512] comedi comedi0: BMCBoard chip select : 0x1
[    7.346518] comedi comedi0: BMCboard hardware rev 3
[    7.346523] comedi comedi0: BMCboard board revision detection started, board_rev value 0x3
[    7.346541] comedi comedi0: PIC18F57Q84 DAQ device, SPI slave mode
[    7.346550] comedi comedi0: PICSL12 device detected, 16 channels, range code 0, device code 0, bits code 0, controller code 3
[    7.346557] comedi comedi0: BMCboard SPI setup: spi cs 1: 8000000 Hz: mode 0x3: assigned to controller device PICSL12
[    7.346568] comedi comedi0: 16 bit and less device buffers set to 16 bits
[    7.348015] comedi comedi0: Analog Out channels 1, Analog In channels 16 : Q84 config code 0x0
[    7.348039] comedi comedi0: DISPLAY, RS232/TTL and device serial TX/RX channels 8
[    7.348045] comedi comedi0: Digital Out channels 16
[    7.348051] comedi comedi0: Digital In channels 24
[    7.351448] comedi comedi0: ao device thread start
[    7.351773] comedi comedi0: driver 'daq_bmc' has successfully auto-configured 'BMCboard'

A C program on the Linux machine uses the driver to send and receive data using MQTT to Home Assistant for monitoring and control of a small Solar Energy testing system.

 

[FactChecker]

No, nothing like that. You don't have to keep track of time. That sounds more like low-level real-time programming, as a guess. I don't have any experience doing that sort of programming.

Thanks for clarifying. I conclude that I was just confused about RISK. The demand for programmers when RISK began was probably just part of the startup of RISK. I never programmed or even saw RISK programs and thought it must be like low-level array processor programming.
Now that I think about it, the timing of RISK should be simpler than with CISK since all the instructions are simple, one-cycle execution. (I guess)

 

[Mark44]

Now that I think about it, the timing of RISK should be simpler than with CISK since all the instructions are simple, one-cycle execution. (I guess)

The instructions are not necessarily one cycle. See this reference for cycle times for one version of ARM, a RISC assembly language -- https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4 Instruction Timing.pdf

BTW, the acronyms are RISC and CISC -- neither includes the letter K.

 

[FactChecker]

The instructions are not necessarily one cycle. See this reference for cycle times for one version of ARM, a RISC assembly language -- https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4 Instruction Timing.pdf

Thanks!

BTW, the acronyms are RISC and CISC -- neither includes the letter K.

AAARRRRRGGGGHHHH!
I hereby disqualify myself from any further comments on this subject.

 

[Rive]

I got the (maybe incorrect) impression that RISC programming was harder when there was a great shortage of RISK programmers.

It was more about the scope of typical application. X86 got lot of programmers since it was a widely used open platform. The RISC competed on lot more specific markets.

all the instructions are simple, one-cycle execution.

Well... not really, but could be felt that way.
source

Execution of one singular instruction was always multiple cycles, but there was several instructions in the pipeline simultaneously, with one 'released' each cycle (if conditions were right).

I think the difference between RISK versus CISK is more significant than that.

Well... no. You can think of CISC instructions as a macro of RISC ones.
And beginning with the Pentium Pro in 1995 (last 'real' x86 CISC from Intel was Pentium in 1993) it was all about the CPU decoding the complex CISC instructions into standardized RISC ones internally, to be executed on a RISC core inside.

 

[sbrothy]

Thanks!

AAARRRRRGGGGHHHH!
I hereby disqualify myself from any further comments on this subject.

We all ef up from time to time.

 

[Mark44]

We all ef up from time to time.

Amen to that!

 

[sbrothy]

Ah.

Then thinking more about it, I retract my comments on sealioning and apologize unequivocally. I obviously misunderstood @elias001 's level of commitment.

Sorry.

EDIT: So yeah, we all ef up from time to time.

 

[sbrothy]

I also think you should look a micro-controllers/embedded systems to gain experience with ASM programming and embedded system design. Embedded systems are much more than low-level programming. IMO spending a lot of time and energy on assembly language for complete programs is a waste of resources for most people in the field. You effectively need to create your own HLL to program larger programs with ASM so it's usually better to use an HLL like C that allows easy integration with ASM for hardware specific functionality.

My current home project requires PIC18 firmware for a board I designed with just a little ASM for things you can't do in C. The PIC assembly is simple and direct.
https://github.com/nsaspook/mqtt_comedi/tree/fixes/bmc
Reading PIC18 device registers in main.c

device_id_data_t DeviceID_Read(device_id_address_t address)
{
    device_id_data_t deviceID;

    //Save the table pointer
    uint32_t tablePointer = ((uint32_t) TBLPTRU << 16) | ((uint32_t) TBLPTRH << 8) | ((uint32_t) TBLPTRL);

    //Load table pointer with Device ID address
    TBLPTRU = (uint8_t) (address >> 16);
    TBLPTRH = (uint8_t) (address >> 8);
    TBLPTRL = (uint8_t) address;

    //Execute table read and increment table pointer
    asm("TBLRD*+");

    deviceID = (device_id_data_t) TABLAT;

    //Execute table read
    asm("TBLRD*");

    deviceID |= (device_id_data_t) (TABLAT << 8);

    //Restore the table pointer
    TBLPTRU = (uint8_t) (tablePointer >> 16);
    TBLPTRH = (uint8_t) (tablePointer >> 8);
    TBLPTRL = (uint8_t) tablePointer;

    return deviceID;
}

This PIC device talks with a Linux system using a kernel protocol driver module that talks to a Orange Pi via SPI.

Driver daq_bmc
https://github.com/nsaspook/mqtt_comedi/blob/fixes/daq_bmc/daq_bmc.c

 spibmc spi1.1: spi link version 1.3
[    7.345168] spibmc spi1.1: BMCboard default: do_conf=1, di_conf=1, daqbmc_conf=0
[    7.346479] comedi comedi0: bmc protocol version 0.96
[    7.346502] comedi comedi0: 4 cpu(s) online for threads
[    7.346512] comedi comedi0: BMCBoard chip select : 0x1
[    7.346518] comedi comedi0: BMCboard hardware rev 3
[    7.346523] comedi comedi0: BMCboard board revision detection started, board_rev value 0x3
[    7.346541] comedi comedi0: PIC18F57Q84 DAQ device, SPI slave mode
[    7.346550] comedi comedi0: PICSL12 device detected, 16 channels, range code 0, device code 0, bits code 0, controller code 3
[    7.346557] comedi comedi0: BMCboard SPI setup: spi cs 1: 8000000 Hz: mode 0x3: assigned to controller device PICSL12
[    7.346568] comedi comedi0: 16 bit and less device buffers set to 16 bits
[    7.348015] comedi comedi0: Analog Out channels 1, Analog In channels 16 : Q84 config code 0x0
[    7.348039] comedi comedi0: DISPLAY, RS232/TTL and device serial TX/RX channels 8
[    7.348045] comedi comedi0: Digital Out channels 16
[    7.348051] comedi comedi0: Digital In channels 24
[    7.351448] comedi comedi0: ao device thread start
[    7.351773] comedi comedi0: driver 'daq_bmc' has successfully auto-configured 'BMCboard'

A C program on the Linux machine uses the driver to send and receive data using MQTT to Home Assistant for monitoring and control of a small Solar Energy testing system.

View attachment 365201

View attachment 365202

Looks exciting. I understand there are a lot of DIY projects out there making use of these cigarette pack-size mini-computers like the Raspberry PI and others. Those might make a good place to start a project writing a device driver or something similar.

 

[nsaspook]

Looks exciting. I understand there are a lot of DIY projects out there making use of these cigarette pack-size mini-computers like the Raspberry PI and others. Those might make a good place to start a project writing a device driver or something similar.

It's mainly a redesign of a larger system already in use. The Raspberry PI and its kin make excellent platforms for small embedded system if you need interactive control and/or compute capabilities in a small package.

Post in thread 'Can Solar Panels Harness Power from the 'Super' Moon for Data Collection?'

Sep 9, 2015

Setting up a new rig for the Super Blood moon this month. I'll use a RPi2 this time for the data logger with another custom Linux kernel driver for the ADS1220 24bit ADC chip via the SPI port.
Just finished up the hardware and software calibration with a old Omega CL511 calibrator.

A few pics of the test setup and build.
The home workshop is a bit of a mess but it's all working now.

Using a 4.998k load resistor for the solar panel and the calibration voltage adjustments @ 2000mV from the standard. The application program 'moonlight' logs the data to a...

• nsaspook

• 

Solar panel ADC front-end for processing low light-level signals.

 

[Rive]

So say I wrong an assembly program to control some tiny devices. Is that finished program call "firmware"?

Missed this one.
Well, yes. Firmware is the software of an embedded system: usually installed in factory and not meant to be modified by the user. So if you 'finish' it and it is doing something for you, then as 'factory', you have the right to call it firmware
Can be anything from a few kB code to a complete OS with a GUI.

 

[sbrothy]

The instructions are not necessarily one cycle. See this reference for cycle times for one version of ARM, a RISC assembly language -- https://www.cse.scu.edu/~dlewis/book3/docs/Cortex-M4 Instruction Timing.pdf

BTW, the acronyms are RISC and CISC -- neither includes the letter K.

At a place I worked my webapp had to request data from an IBM CICS [sic!] backend on a mainframe. They kept referring to it as the KIKS server. A little annoying as “kiks” in Danish means biscuit and is a colloquialism (?) for failure.