Due to Covid-19 and certain marketing constraints, No Starch Press is putting off the formal release of “The Art of 16-Bit Assembly Language” until January 11, 2022. However, if you pre-order a copy (https://nostarch.com/art-64-bit-assembly), they will send you a hard copy as soon as they arrive from the printers (expected date: Oct 20, 2021). Of course, electronic copies will be available after that date as well.
Sorry for the confusion and delays. Pray that next year the pandemic will start to become a bad memory.
Hi Randall,
With much anticipation, I finally received the book yesterday (I had pre-ordered the Amazon Kindle version in February!). Unfortunately, the source code in the eBook looks jumbled up and hard to read. Basically, the *formatting* of the source code i.e. spaces and new lines, is messed up. I have tried viewing it on Kindle for Android app, online (read.amazon.com), and on the Kindle for PC desktop app, and it’s the same issue on all of them. I even downloaded a sample of the book on Google Play Books and it was exactly the same.
I just used Amazon online chat and informed the customer service agent about this. All I got was “I will escalate this to the appropriate team”. Unfortunately, I won’t get any updates about this issue from them. I don’t want to cancel the purchase either, as I really want the book and to keep the pre-order discount. The downloadable source code from the book’s site is fine; they display nicely in a text editor. However, not all the code that is in the book is available in there.
I do hope this is sorted out and can possibly get an updated version if this is fixed.
Thanks.
I have no idea how the Kindle version was created. Probably something Amazon did when given a PDF. I can only vouch for the hard copy, which NSP and I worked on very carefully to ensure the listings were formatted properly and readable. No doubt, conversion to Kindle was some automated process and (as is typical for EPub style books), the formatting changes radically based on screen size.
The full program listings are available from my web site; that won’t help you so much with code snippets and the like, however.
Cheers,
Randy Hyde
Good morning Mr. Hyde.
There is question that probably you had already answered in many places but i am new to this and i couldn’t go over all the places already:
HLA for Mac OSX >>>> 64 bits ?
I would want to do all exercises in your books so i need it. If there is no, as i read in some places, what could be the alternative? Any other assembler that has the closest instructions/syntactics/structure so i can adapt to it with little effort?
What would be the best approach in any situation like this?
I’m afraid assembler it would be hard enough to understand to put over another layer of complexity…
Thank you Mr. Hyde. Any advice would be gold.
HLA is a 32-bit application written in a combination of Bison, Flex, C/C++, and assembly language (HLA). Largely because of the HLA component, it really would be too much work to convert HLA to a 64-bit assembler; that would largely involve rewriting it from scratch which, including the HLA standard library, is about 400-500,000 lines of code. As I have so many other projects that are a much higher priority right now, I don’t see any chance that I will ever work on HLA again.
However, there is a different solution to your problem. I have written a 64-bit version of “The Art of Assembly Language” (“The Art of 64-bit Assembly”). That edition uses the Microsoft MASM assembler, which is readily available.
https://www.amazon.com/Art-64-Bit-Assembly-Language/dp/1718501080/ref=sr_1_3?crid=1BLQTIRP1DZAN&keywords=art+of+64+bit+assembly&qid=1637801704&sprefix=art+of+64%2Coutdoor-recreation%2C178&sr=8-3
Hello, I just bought The Art of 64-Bit Assembly, Volume 1. I am curious about Volume 2. Any details on it?
Volume 2 is sitting at No Starch in the queue.
Editing will probably begin *after* I finish “The Art of ARM Assembly.”
Given pandemic issues, I’d expect it to appear within two years.
Cheers,
Randy Hyde
Thanks. I am looking forward to it!
Hello, Dear,
I started following the HLA tool and compiler for windows. I saw that you have a version 3.0 (Code only). Can you leave somewhere, github or on your website the procedures so you can compile a .EXE version for Windows 10? Thank you very much. https://www.plantation-productions.com/Webster/HighLevelAsm/hla3/0_hla2.html
HLA v3.0 was a project that got about half-way done and then I abandoned it because it was clear that 32-bit code was fading away. You can no longer run 32-bit code on macOS and Linux is making it harder every day. Yeah, Windows still supports it, but for how long? (See Windows 11 for a whole new set of restrictions.) Because HLA v3.0 is written in HLA itself, it would be a tremendous amount of work to re-write it to produce 64-bit code. I originally wrote HLA v3.0 to prove that an HLA-syntax assembler could be very fast (HLA v2.x and earlier were very slow due to the use of flex/bison for the parser and macro processor). The HLA v3.x parser is *very* fast (blowing away every other x86 assembler I’ve seen). However, once I proved the point, I really lost interest as faster machines reduced the need to speed up HLA (what a statement coming from someone who pushes assembly programming!) and other projects took precedence.
HLA v3.0 source code (https://www.randallhyde.com/AssemblyLanguage/RollYourOwn/index.html) can be compiled by HLA v2.x to produce an executable. However, only the scanner/parser is functional at this point; what’s missing is the code generator.
I *may* look at HLA again in the distant future (in particular, an ARM version would be interesting), however I have so many projects in the works right now that I doubt I’ll have time to look at this any time soon.
I really understand what you’re saying. Inspiring to see who created and developed the HLA. Are you working on some new language? The important thing in all that left a legacy. Thanks!
From Brazil.
Hi, hope you doing well.
I think I found typing mistake in the book.
Section 1.16.1 Variable Size:
In Table 1-6
Signed char and char both have type “sbyte”
Regards
Technically, this is correct.
C/C++ define char types to be signed values (i.e., sbyte).
You must use C’s “unsigned char” type for unsigned values (i.e., byte).
Of course, 64-bit MASM treats byte and sbyte exactly the same, so it won’t make a difference.
Actually as far as c99 goes, the standard does not define char to be signed or unsigned, rather, I am pretty sure they say it is implementation defined. If the programmer wants, he should put the type specifier that he wants
Hey,
you think this book will help me write assembly syscalls on unix/linux systems?
what files does masm produce? win64 exexcutables only?
The book was written specifically for MASM/Windows. However, there are sample programs written in Gas (and clang asm) for Linux and macOS. However, the book was written to teach assembly language (in general), not making system calls (Windows, Linux, or macOS) from assembly. That said, there is one chapter at the end on standalone assembly programs (which make system calls). The Gas examples work under Linux. That said, this is only one small chapter in a 1,000-page book. So I don’t want you to get the idea that this is the perfect book for your purposes.
OTOH, once you’ve master x86 assembly, learning Linux system calls is actually pretty easy (there’s documentation on my web site that describes this, for example).
Your LinuxSysCalls.pdf documentation, right? That is some very detailed work! Is there more 64bit docs I am missing, or did I find the right one?
I saw in the table of contents that the last chapter is on standalone apps.
So do you mean you can do file IO without needing some headers from Microsoft?
What exactly do you mean by “standalone”
No, what the chapter means is that you can write pure assembly language code, making calls via header files (I use Hutch’s MASM32 header files for 64-bit assembly in the examples).
“Standalone” in the sense that you’re not writing code that is being called by a C/C++ program. Most of the example code in Ao64A uses a C++ “shell” program to call the assembly code so that the assembly code can make use of the C standard library for I/O purposes (replaces the use of the HLA standard library in the original AoA).