Assembly Language StepbyStep Programming with DOS and Linux 2nd Ed [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Assembly Language StepbyStep Programming with DOS and Linux 2nd Ed [Electronic resources] - نسخه متنی

Jeff Duntemann

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید









Your Work Strategy


There are smart ways to work and dumb ways to work. The dumb ways often get the same things done, but for twice the expended time. (Maybe more. How much is your time worth?) It pays to have an organized approach to any kind of programming work, and in this section I'm going to suggest a way of setting up your working environment so that you will waste as little time as possible.


Put Only One Project in One Directory


Traditional practice in the Unix world has long been "one makefile, one directory." What this means is that you should create a separate directory for every project whose end result is a single executable program file. Don't just create one directory for assembly language work and then fill it with umpty-several different projects. This invites confusion, and it makes certain things (such as using the make facility) trickier and more error-prone.

If you confine each project to its own directory, you can keep the default make file named "makefile" and not worry about typing the name of the make file into EMACS each time you want to rebuild the project. (And with only one make file in the directory, you won't have to worry about accidentally invoking make on the wrong make file. I've done this. If you block on it, you'll soon be doubting your sanity.)

This also allows you to have standard names for test files, log files, and so on, that will be identical irrespective of which project you happen to be working on at any given time. If all the files were glommed together in one huge directory, you'd have to remember a whole set of unique names, one set for each project. Why bother? Directories cost little in disk space and do an enormous amount to manage complexity.


Consider EMACS Home


All of the various steps required for programming can be done right from inside EMACS. You can edit source code files and make files. You can assemble files and link them to generate executable files. You can run the executable program files to test them. You can invoke the GNU debugger. You can execute nearly any Unix command that can be issued from inside a Unix shell such as bash. Why waste time ducking in and out of EMACS as though it were nothing more than a text editor?

More than one book has been written about EMACS. I recommend the book Learning GNU EMACS by Debra Cameron, Bill Rosenblatt, and Eric S. Raymond (O'Reilly, 1996). My one gripe is that it doesn't cover the X Window version of EMACS specifically, but all the key commands are the same. I don't want to duplicate a lot of that book's excellent material here, and EMACS is relatively intuitive on the editing side.

The important big-picture thing to understand about EMACS is that it is buffer-based, and those buffers either may be related to disk files, or may simply contain other text that is not from a disk file. When you open a file, EMACS opens a buffer and loads text from the opened file into that buffer. You can also open a buffer as a scratch buffer, type something in it, cut or copy portions of that buffer into another buffer, and then just kill the scratch buffer (delete it) without saving it to disk. (There is a separate EMACS menu item for killing buffers.)

When EMACS runs the make facility, it pipes output from make and from the tools that make invokes into a new buffer. That buffer is the same as any other EMACS buffer, and if you want, you can give the buffer a name and save it to a disk file as a record of the make session. It does the same when you invoke the GNU debugger from inside EMACS: gdb's output is piped into a buffer, which you can save to disk if you choose for later reference.

Most usefully, you can invoke a Unix shell (I use bash) from inside EMACS, and EMACS will pipe its output into a new buffer, which like any buffer can be saved to disk. Especially while you're learning, there's very little that you'll need to do that can't be done either from the EMACS menus or from a shell opened from within EMACS.


Opening a Shell from inside EMACS


This last is worth explaining, because it is less obvious than most of the editing commands. There is currently no EMACS menu item that opens a shell in a window. (There should be!) To open a shell, the command is "Esc x shell." You press the Esc key followed by the lowercase x key (don't press both at once!) and, in its command line at the bottom of its window, EMACS will display the unhelpful string "M-x." This is its way of expressing the sequence Esc x on a PC. (The M stands for "Meta," which was the name of a control key on some ancient and mercifully forgotten minicomputer dumb terminal.) On other computers or terminals that may lack an Esc key, there may be other ways of initiating the command. EMACS was written to be portable. After the string "M-x" you must type "shell" and then press Enter.

EMACS will open a new buffer in a window and will begin piping shell output from the default shell into that window. At the top of the window will be your familiar shell prompt, waiting for you to type shell commands just as you did before you invoked EMACS. You can invoke the executables you build with make by naming them (usually prepended by "./") just as you would from the shell.

Note that you can exit the shell by typing "exit," but the window and buffer that EMACS opened for the shell will not go away by themselves. You have to kill the buffer as a separate operation, using the Files | Kill Current Buffer menu item.

I mentioned it earlier, but keep in mind that you can launch the GNU Debugger by selecting the EMACS menu item Tools | Debugger.


/ 166