|
Not all assembly languages are created the same. The Intel/CISC machine languages have their roots in the old IBM 360 mainframes. These are complex instruction sets that require a lot of hardware to implement. The newer RISC instruction sets trade some of this hardware complexity for a significantly simpler machine language implementation using a lot more instructions to do the same functions. We've found that the RISC machines generally operate faster and can be optimized in ways that CISC cannot, which is why even the CISC instruction set used by Intel to this day has become more of a macro language on an underlying RISC instruction set that Intel has highly optimized.
As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly. It has nothing to do with the actual language. I ran into the same issue when learning Windows programming until I found Charles Petzgold's books. Same language, same OS, but his books were far better at teaching Windows programming.
|
|
|
|
|
obermd wrote: As for having to read 100 pages before getting to the actual assembler, this is the sign of a poor tutorial on assembly.
Yeah, it's a balance. I mean, to really learn what's going on underneath the surface, a lot has to be explained.
And, since learning Assembly means you need to understand so many concepts (number bases, what hardware is actually doing, tools (compiler, linker, make, etc.)) there can be a lot to learn just to get to where you're learning the target thing.
Petzold's books were long and in depth, but I really enjoyed his style and I felt like he was inviting me into a secret club to learn things that few others knew. 
|
|
|
|
|
If you want to learn assembler because you think that you are smarter than the compiler, able to write faster code (you are not!), then you need only learn the syntax of the essential instructions, and you can use the inline assembly facilities provided by a lot of C/C++ compilers.
If you intend to write complete modules in assembly, whether you are developing the backend for a compiler, writing a driver, or a high performance library, then you must understand all that stuff in the first 100 pages.
I very much doubt that there is any description of, say, x64 or AArch64 architecture in less than 100 pages to teach you what you need to know to write a runtime system, even an interrupt handler, a driver or a compiler backend, or a library function, in pure assembler.
Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks.
Disclaimer: I do not know that specific book you are referring to. There are lots of poor books out there. What I am saying is that if you find any book of significantly less than 100 pages introduction to basic concepts of the architecture, they have skipped a lot of stuff that you have to learn from other sources. Te page counts of all those sources will probably add up to a lot more than 100 pages.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: Complaining about 100 pages presentation of the architecture is probably because you think you are not going to need that information. But you are, if you are heading for serious assembler coding tasks.
Oh, I totally agree. And, like I said, Duntemann is one of my favorite authors.
I read the first edition of the same book back in 1993.
It was published as Assembly Language Step-by-Step[^] back then and the book taught me everything I know about low-level programming. It is the first book that helped me understand number bases (binary, decimal, hexadecimal).
So, really my only point is that since I've read those first 100 pages numerous times over the years it was a bit difficult to chew through them again since I was chomping at the bit to get to the good x64 Assembly stuff. 
Duntemann's book is really like a complete school of computing and software development all wrapped up, so in many ways it is a very short book. 
It is often difficult as an "Application Developer" to slow down so much with Assembly.
The things we use now that obfuscate all that stuff below are amazing and troubling at the same time.
Now the devs know "it's easy to create software". But it's still not easy when problems occur and you don't know where (or how) to look.
|
|
|
|
|
Agreed that you really need to know the architecture to get the most out of assembly, but the reality is you can start your journey in a lot fewer pages as many assembly tasks don't require the in-depth knowledge of the hardware.
And yes, I know and have worked in four different machine languages - Intel x86, Motorola 6502, IBM BAL, and Dec's PDP-11. You can learn the architecture as you're learning the machine language.
|
|
|
|
|
 for Charles Petzold
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
If... I do PLC, haven'T touched a uC since college.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Yes, RISC assembly is fun.
Trying to understand the compiler generated RISC assembly is less fun.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I assume you know about the 'fluent api pattern', e.g. in c#, something like:
new MyFluentApi()
.DoThis(x)
.DoThat(y)
.DoAnother(z);
Now, I was looking for that pattern to do a similar thing in Pascal and recognized, that it is allready something like 'build in' since decades 
WITH myFluentThing DO BEGIN
DoThis(x);
DoThat(y);
DoAnother(z);
END;
|
|
|
|
|
Yep
Relearning Pascal, Turbo Pascal 3.0 on a RC2014 Z80 hardware running under CP/M 2.2.
Been since college days the last time I even saw any Pascal code. Wrote a couple of simple apps, still learning.
Learning the editor is twice as hard as the code. We sure take modern editors for granite.
If you can't find time to do it right the first time, how are you going to find time to do it again?
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
To be honest, I don't know Pascal really. I was a Modula2 Guy for decades (Modula also invented by Niklaus Wirth, the Pascal inventor I think).
And yes, I hate the 'WITH' in Pascal/Modula (especally when nested), but now I recoginze, it can be usefull too
|
|
|
|
|
Modula is available to run on CP/M, been thinking about kicking the tires.
Going on vacation tomorrow for a week but may give it a whirl when I get back.
If you can't find time to do it right the first time, how are you going to find time to do it again?
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Enjoy your vacation
|
|
|
|
|
I was stunned by "FluentApi" when I heard the term.
I first saw it in modern times in C# unit testing and all these new devs were like "fluent api is so special...oh, wow, this new fluent api is just so amazing."
I was like, "what is fluent api?"
Then I saw it was something we were doing in C++ (specifically MFC/C++) back in 1995 or something.
Ok, so you return an object from the method and then you can call another method on the object immediately.
These new technologies which are 25 years old are so amazing!! 
Bell bottoms are in too and they are also amazing new technology that the world has never seen. 
|
|
|
|
|
|
I know some Clapton but hadn't heard that song. Great stuff! Sounds great and it's live.
Thanks for sharing. 
|
|
|
|
|
Mike Hankey wrote: Been since college days the last time I even saw any Pascal code.
Was Pascal already there when you went to college?  
Sorry... I could not avoid it
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Towards the end, started out with PL/1.
No seriously we would scratch 1s and 0s in the sand and wait for the guy named Alu to come around with his abacus and perform the operation for us.
I'm so old I was the counter for Noah, but I was fired for letting cockroaches on the ship. In my defense I was busy picking out two of the female species to load.
If you can't find time to do it right the first time, how are you going to find time to do it again?
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Mike Hankey wrote: I'm so old I was the counter for Noah
So you have changed your name since? I mean, if you survived the flood, you must have been one of his sons...
I was busy picking out two of the female species to load Have you noticed that a large fraction of the pictures made of the animals entering the ship, two by two, where the two lions both have large manes? I wonder how we can have lions today...
But then, we are getting close to the yearly rainbow festivals, which is a good occasion to bring up these drawings/paintings.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Add to that the fact that 2 individuals are not enough to re-establish a population.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I guess that my background with Pascal and WITH as a student is a major reason why I never use this.something when programming in OO languages.
As classical Pascal did not have classes, you could not put functions manipulating the object (aka. RECORD) into the object definition itself. For functions that would later, in OO languages, become methods of the class, WITH was a nice way to simulate that you were inside the object definition.
I never understood why some people insist on using this. everywhere. I read it as a warning: The simple identifier would be ambiguous, and this. is a way to resolve the ambiguity. Sort of like always including the full path from the complete namespace name down to the method name when calling it. I guess my negative reaction to both is that I grew up with WITH as standard way to indicate that 'Now I am manipulating this object'.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
That Pascal code isn't anything fluent at all, it's just a series of method calls. The direct equivalent of the C# code would be (removing the use of WITH as an anti-pattern):
var myFluentThing := TFluentThing.Create
.DoThis(x)
.DoThat(y)
.DoAnother(z);
This is only possible, as is true for C#, if the DoThis and DoThat functions return an instance of the TFluentThing class.
|
|
|
|
|
But at the end comes nearly to the same
|
|
|
|
|
Ermmm, no, because that is like saying 2 + 2 = 3, because 3 is nearly 4
|
|
|
|
|
In the C# chain, methods may return the same or different objects at any stage.
The WITH block just calls the methods on the original object.
IThing thing = new ThingBuilder()
.AddTitle("I'm a Thing!")
.CreatePreciousThing()
.SetPreciousLevel(100);
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
