I have completed my update to "Introduction to 64 Bit Intel Assembly Language Programming for Linux". It will be visible on Amazon and Barnes and Noble within a week - probably by July 4. It is available right now from Create Space at https://www.createspace.com/3917966 for the same price as the first edition: $29.95.
The second edition is 308 pages while the first edition as 253 pages. There is very little additional assembly language content, though there are some expanded discussions and a few more examples. The chapters have the same titles. The primary change is the introduction of the ebe IDE for assembly language programming.
The cover art is nearly the same. The OpenGL program producing the intertwined cycle (it is indeed 1 cycle) is more colorful, though I toned it down somewhat from my original tubular.cpp code.
I have started revising my web pages at http://www.rayseyfarth.com to include more graphics. I intend to include a fairly extensive tutorial on ebe at http://www.rayseyfarth.com/ebe. I will also have PDF slides, source code and corrections for the book available at http://www.rayseyfarth.com/asm. I have left the original assembly language web site accessible from a link near the bottom of my main web site.
A new feature I have planned for the next few months is to prepare some assembly language tutorials which will be accessible from http://www.rayseyfarth.com/asm. I plan to host these on youtube, but I haven't started yet... Real soon now...
Tuesday, June 26, 2012
Sunday, June 24, 2012
Kompozer
I decided I needed to start working once again on my web pages. The main page for http://www.rayseyfarth.com has been too boring. It has been simple text on a light yellow background. So I did a little googling and found that people liked bluefish pretty well. So I gave it a whirl.
I rapidly got tired of viewing the html code. It's tedious thinking in terms of a markup language when what you are thinking about is conceptually simpler. I know that I have used LaTeX for my textbook, but at least it offers some interesting things like excellent equation formatting and I also have figured out how to use htlatex fairly well to produce an ebook.
So it was time to try google again. This time I tried "wysisyg html linux" and found that people recommended kompozer. So I installed kompozer and started using it.
I found that you still have html structures at work, but you can work on them while seeing the page roughly as it ultimately will look. You can also switch over to editing the html to add a few tweaks. This seems like an acceptable compromise to me.
I have the basics of a fairly nice web site started now. I have lots of color on the front page and hopefully I haven't gone too far in the other direction. I would hate to be gaudy.
I rapidly got tired of viewing the html code. It's tedious thinking in terms of a markup language when what you are thinking about is conceptually simpler. I know that I have used LaTeX for my textbook, but at least it offers some interesting things like excellent equation formatting and I also have figured out how to use htlatex fairly well to produce an ebook.
So it was time to try google again. This time I tried "wysisyg html linux" and found that people recommended kompozer. So I installed kompozer and started using it.
I found that you still have html structures at work, but you can work on them while seeing the page roughly as it ultimately will look. You can also switch over to editing the html to add a few tweaks. This seems like an acceptable compromise to me.
I have the basics of a fairly nice web site started now. I have lots of color on the front page and hopefully I haven't gone too far in the other direction. I would hate to be gaudy.
Monday, June 18, 2012
F and C Bits
Introduction
This essay started as a brief introduction to some of the weird things I have seen on assembly languages through the ages. Then the essay turned into a search for documentation of the F and C bits for the SEL computers from a long, long time ago. I needed a shell loop to fetch some files with wget and things unfolded.I found an old manual which someone kindly scanned and placed online for the SEL 32/70 CPU. I did some fairly interesting work with a "desktop" model, the 32/27. It was advertised as being in a small box (when boxes were much bigger). It had cards which I believe were 19 inches wide and slid nicely in a cabinet with the bus running vertically in the back of the cabinet.
Tuesday, June 12, 2012
No color book ;-(
I have started revising my assembly book with the primary change being the description of using ebe for code development. Ebe uses a handful of different colors, so it would be nice to print the next edition in color. The number of screen shots in the book would be perhaps 50 and each picture could be arranged to use a small amount of toner. It seemed possible that if Create Space used some sort of printer a bit like a laser printer that perhaps a color edition of my book might be moderately cheap.
I submitted a question to Create Space and the answer was 12 cents per page for the whole book if there were any color on the inside. Assuming about 300 pages this would be $36.00 just for the per-page printing cost and the original book's list price was $29.95, so the price would need to be about twice as much. This is clearly not a sensible decision. I think that a color book for the same price might increase sales, but twice as much money sounds excessive. That would be something like the typical book cost and I personally want to keep the cost down. It might be possible to sell more expensive books, but I don't want to waste people's money.
I modified the ebe program to accept a "-g" command line option to switch it into a grayscale mode which should result in higher quality images than converting color images to grayscale. Now I am back to work updating the book.
I submitted a question to Create Space and the answer was 12 cents per page for the whole book if there were any color on the inside. Assuming about 300 pages this would be $36.00 just for the per-page printing cost and the original book's list price was $29.95, so the price would need to be about twice as much. This is clearly not a sensible decision. I think that a color book for the same price might increase sales, but twice as much money sounds excessive. That would be something like the typical book cost and I personally want to keep the cost down. It might be possible to sell more expensive books, but I don't want to waste people's money.
I modified the ebe program to accept a "-g" command line option to switch it into a grayscale mode which should result in higher quality images than converting color images to grayscale. Now I am back to work updating the book.
Assembly language on the Mac
Thanks go to Daniel Bond who allowed me to test ebe on his latest Mac laptop. The Mac turns out to almost be great for running ebe.
At first the program was dying due to yasm not being in the path. After solving that minor issue it worked fairly well with C and C++. But assembly language was not quite ready for prime time.
The first issue is that the Mac standard requires prefixing global symbols with an underscore, so I had to change my test program to define _main and call _write and _exit. I have run into this pattern before and it seems to be fairly common. That was quickly solved and then it was time to move on.
I ran gcc with the -S option to dump assembly code and found that it thought that the segments might need to be named __text and __data, but that turned out to be a non-issue. After a bit of effort I returned to .text and .data and managed to get my test program to link.
I ran into an issue with the command "mov rsi, msg" where msg was a label for an array of chars to send to _write. yasm complained that it couldn't use a 32 bit constant here. I don't fully understand why this message occurred on the Mac and not on Linux. However I got past this issue and used "mov rsi, qword msg" which resulted in a program which printed "Hello World!".
Update(Nov 13, 2012) The Mac uses addresses which are too big to fit in 32 bits. The instruction set has a 32 bit address/offset field. Adding "default rel" tells the assembler to generate rip relative addresses. So the better choice would be "lea rsi, [msg]". This is a load effective address instruction. The address field will be the difference between the address of msg and register rip (after this instruction). I eventually rolled my own in ebe with respect to gdb not knowing about line numbers.
That was not too difficult to cope with, but I ran into a problem for which I did see a solution. I did not find a debugging format choice for yasm on the Mac. Without debugging information I could build a program and execute it with no feedback. This is not acceptable. I poked around with nasm for a few minutes and it appears that nasm is 32 bit only. Both the lack of a debug format and lack of 64 bit nasm seem to be problems which should have a solution.
I am on a fairly tight schedule to try to get a new edition of my assembly book done early in July. I decided that I should not spend further time right now trying to get ebe functional with assembly language on the Mac. I would like to explore it further later.
At first the program was dying due to yasm not being in the path. After solving that minor issue it worked fairly well with C and C++. But assembly language was not quite ready for prime time.
The first issue is that the Mac standard requires prefixing global symbols with an underscore, so I had to change my test program to define _main and call _write and _exit. I have run into this pattern before and it seems to be fairly common. That was quickly solved and then it was time to move on.
I ran gcc with the -S option to dump assembly code and found that it thought that the segments might need to be named __text and __data, but that turned out to be a non-issue. After a bit of effort I returned to .text and .data and managed to get my test program to link.
I ran into an issue with the command "mov rsi, msg" where msg was a label for an array of chars to send to _write. yasm complained that it couldn't use a 32 bit constant here. I don't fully understand why this message occurred on the Mac and not on Linux. However I got past this issue and used "mov rsi, qword msg" which resulted in a program which printed "Hello World!".
Update(Nov 13, 2012) The Mac uses addresses which are too big to fit in 32 bits. The instruction set has a 32 bit address/offset field. Adding "default rel" tells the assembler to generate rip relative addresses. So the better choice would be "lea rsi, [msg]". This is a load effective address instruction. The address field will be the difference between the address of msg and register rip (after this instruction). I eventually rolled my own in ebe with respect to gdb not knowing about line numbers.
That was not too difficult to cope with, but I ran into a problem for which I did see a solution. I did not find a debugging format choice for yasm on the Mac. Without debugging information I could build a program and execute it with no feedback. This is not acceptable. I poked around with nasm for a few minutes and it appears that nasm is 32 bit only. Both the lack of a debug format and lack of 64 bit nasm seem to be problems which should have a solution.
I am on a fairly tight schedule to try to get a new edition of my assembly book done early in July. I decided that I should not spend further time right now trying to get ebe functional with assembly language on the Mac. I would like to explore it further later.
Friday, June 08, 2012
Updating the Assembly Book
I've been updating my assembly textbook. The biggest change is clearly the introduction of the ebe development environment. It's a fairly crude IDE designed primarily for assembly. It's either part of my effort to make learning assembly language easier or a fairly crude attempt to sell more books. My opinion is that is clearly a bit of both.
I got pretty tired of trying to use gdb in class when I taught assembly language. I felt that debugging was critical for assembly language and gdb was too much trouble. I tried to make some changes to a handful of IDEs to support assembly language better and I did make some improvements, but it was still a bit of an unnatural mess to use.
Ebe is a godsend to assembly language. It makes it much easier to use a debugger and I hope that translates into easier for people to learn to like assembly language. It's the great grand-daddy language of them all and forms the cornerstone of rational debugging.
The problem is that I could include an enormous number of pictures captured from ebe in the book. This would drive up the cost of the printed book. On the other hand it makes the book more valuable and will increase sales - up to some point. So there is a maximization problem. I don't know the relationship of sales to number of pictures, so I can only guess.
The images would look better in color, but the book would lose me money at the current price. There should be a charge difference based on the amount of color toner used, but the charge ignores the actual costs. I diagram with red and blue lines in 500 pages would incur the same charge as full color photographs on each page. That's crazy. Maybe Create Space can cope with a wee bit of negotiation. I doubt that having 50-100 half page or less diagrams with 5-10% filled dots would have much serious effect on printing cost. It certainly wouldn't make much difference with a color laser printer and surely that is cheap enough. Probably book format pages cost under $0.002 per page. That's 2 tenths of a cent per page or 1 dollar for a 500 page book. It really should be possible for Create Space to allow color textbooks to be printed on an actual cost (plus profit) basis. This would increase their sales!
I got pretty tired of trying to use gdb in class when I taught assembly language. I felt that debugging was critical for assembly language and gdb was too much trouble. I tried to make some changes to a handful of IDEs to support assembly language better and I did make some improvements, but it was still a bit of an unnatural mess to use.
Ebe is a godsend to assembly language. It makes it much easier to use a debugger and I hope that translates into easier for people to learn to like assembly language. It's the great grand-daddy language of them all and forms the cornerstone of rational debugging.
The problem is that I could include an enormous number of pictures captured from ebe in the book. This would drive up the cost of the printed book. On the other hand it makes the book more valuable and will increase sales - up to some point. So there is a maximization problem. I don't know the relationship of sales to number of pictures, so I can only guess.
The images would look better in color, but the book would lose me money at the current price. There should be a charge difference based on the amount of color toner used, but the charge ignores the actual costs. I diagram with red and blue lines in 500 pages would incur the same charge as full color photographs on each page. That's crazy. Maybe Create Space can cope with a wee bit of negotiation. I doubt that having 50-100 half page or less diagrams with 5-10% filled dots would have much serious effect on printing cost. It certainly wouldn't make much difference with a color laser printer and surely that is cheap enough. Probably book format pages cost under $0.002 per page. That's 2 tenths of a cent per page or 1 dollar for a 500 page book. It really should be possible for Create Space to allow color textbooks to be printed on an actual cost (plus profit) basis. This would increase their sales!
Subscribe to:
Posts (Atom)