Re: Machine code and assembly are necessary currently?
Posted: Wed Mar 28, 2018 8:12 am
I meant to ask about this earlier: was that the link you meant to give us? It seems to be a slide from a talk about assembly programming (or more likely, compiler optimization - I will explain why I am saying this shortly). It seems to be showing a graphical debugger displaying the progress of a program as it adds a value to every element of an array, as a series of individual instructions in a linear sequence. While preparing such a slide does require some understanding of assembly, it is not a program itself, only a fragment of one, and a very small fragment at that.igorov70 wrote:He backing up oppinion with his 30 years not me i dont have 30 years and not me who must show thing. BUT: https://imgur.com/a/1edUT This i has made for a high scool for teach x86 assembly.StudlyCaps wrote: ......
I am assuming you meant to link to a repo somewhere, rather than this.
Or maybe not, given what we can surmise about the slide itself.
My impression is that it is meant to show how a short loop can be unrolled, a typical method of trading space for speed (as even a branch to a target that is inside the CPU pipeline is costly, so the idea is that if the loop body is short, you can stretch it out to almost fill the pipeline and branch less often).
While it does come up in hand-coded assembly a lot, this sort of slide seems a lot more typical of one that would be used in a talk on writing a peephole optimizer which would transform the output of a compiler's code generator to unroll such loops automatically.
It is also a technique associated less with microcontrollers (which are often memory-constrained, but do not have extremely high speed performance demands) than with general-purpose systems (where programmers generally can afford to apply extra memory to break speed bottlenecks). While unrolling loops does make sense in some contexts regardless of whether the CPU has an instruction pipeline or not (8-bit and 16-bit architectures generally don't, 32-bit and 64-bit ones almost invariably do), when there is an instruction pipeline, then the value of unrolling is tightly determined by the pipeline size, so hand-unrolling becomes much harder on a pipelined architecture.The pipeline sizes in a CPU family can vary from model to model, so either it has to be applied separately for each CPU model (and the installer would then need to use the correct version for the machine in question), or it has to target the lowest common denominator and lose some of the benefits of unrolling.
Presumably, this is why the slide is showing x86 assembly language, rather than, say, 8051 or AVR. While the 80186 is still fairly common for some embedded work, in general x86 family chips are only found on systems derived from the PC these days (an irony I have discussed before, given Intel's intentions with the 8086 line). Since this code is for a later 32-bit model (given the reference to the 32-bit EIP rather than the 16-bit IP of the 8086/8088, 80186, and 80286), that mostly rules out it's use in an embedded system (though not entirely, as the Edison series chips do have roles of that sort). Given what I already said about pipelines, this lend further credence to the idea that it is from a lecture on compiler optimization rather than one about general assembly programming.
You did say it was for a course, though, so perhaps the class could have been about PC assembly programming. Nonetheless, I still think compiler design is the more likely subject of this slide.
If your intent was to show your assembly programming skill, well, the slide you have given us only raises more questions. I am will to give you the benefit of the doubt, however, and assume that this was not what you meant to post.
I am similarly interested in hearing your explanation of the comment about 'programming microcode', since, if taken at face value, it seems like an absurd claim - microcode is only 'programmed' in the loosest of senses, and that work would generally be the province of the CPU designers, not software engineers. I am still guessing that you meant some other sort of firmware, but I would prefer to hear what you have to say on that rather than make blind assumptions.