Under Linux, Mac OSX, and FreeBSD, HLA will produce a low-level assembly language output file that you can assemble using the Free Software Foundation’s Gas assembler. The HLA package contains the HLA compiler, the HLA Standard Library, and a set of include files for the HLA Standard Library. I’d like to know how can I do a simple assembly program for Mac OS X that shows a window on the screen and put some coloured text on that window. The code may call some Carbon.
|Initial release||September 24, 1986; 34 years ago|
|Operating system||Classic Mac OS|
|Type||Software development tool|
|Website||Official MPW website at the Wayback Machine (archived May 14, 2011)|
Macintosh Programmer's Workshop or MPW, is a software development environment for the Classic Mac OSoperating system, written by Apple Computer. For Macintosh developers, it was one of the primary tools for building applications for System 7.x and Mac OS 8.x and 9.x. Initially MPW was available for purchase as part of Apple's professional developers program, but Apple made it a free download after it was superseded by CodeWarrior. On Mac OS X it was replaced by the Project BuilderIDE, which eventually became Xcode.
MPW provided a command line environment and tools, including 68k and PowerPC assemblers as well as Pascal, C and C++compilers. The shell environment is somewhat similar to Unix shells in design, but is designed around the Macintosh's character set and GUI, replacing the usual terminal environment with a 'worksheet' interface, allowing the user to select and run arbitrary sections of a shell script or to redo commands with no retyping. In addition, command line tools were commonly provided with a somewhat standardized graphical interface named Commando that provided limited access to the command line capabilities of the program. The debuggers were not integrated into MPW like most IDEs of today but the language compilers supported the symbolic debugging information file format used by the debugger. MPW supported a source-level debugger called SADE (Symbolic Application Debugging Environment). SADE was not an MPW Tool, but ran as a separate application with a user interface similar to MPW.
Apple's compilers had some features that were not common on other platforms—for example, the Pascal compiler was object-oriented, while the C and C++ compilers included support for length-prefixed strings (needed for Pascal-oriented APIs).
Pascal was Apple's original preferred language for Macintosh software development, and MPW was initially released with only Pascal support. A C compiler was released with MPW 2.0. The MPW C compiler was written under contract for Apple by Greenhills. In addition, the original MPW C compiler was known for its casual and frequently humorous error messages ('we already did this function'), as well as occasionally addressing users by name. These quirks were not carried on after the PowerPC transition, when Apple replaced the originals with compilers written by Symantec. Pascal support was no longer provided by the mid-90s due to declining popularity of the language.
MPW was always targeted to a professional audience and was seldom used by hobbyist developers due to the considerable price for the package; by the time it was made freeware it had long since been superseded by offerings from Symantec and Metrowerks, as well as Apple's own development tools inherited from NeXT and distributed for free with OS X. It was also occasionally available as a wrapper environment for third-party compilers, a practice used by both Metrowerks and Absoft among others. Apple has officially discontinued further development of MPW and the last version of OS X to run it is 10.4 'Tiger', the last one to support the Classic environment. Apple maintained a web site and mailing lists that supported the software long after its discontinuation, but that site now redirects to the Xcode page.
The MPW Shell featured redirection of output to files, as well as to windows. If a file were open, the output would go to the file and to the open window. This redirection of output required significant patching out of the file system calls so that tools need not do anything special to inherit this feature: the MPW Shell did all of the work.
The MPW Shell command language was based on the Unix csh language, but was extended to support the main features of the Macintosh GUI. It had simple commands to create menus, dialogs (prompts), and new shell windows. The cursor could be controlled, and MPW scripts or tools could easily be attached to a menu item. Command key shortcuts could be specified. Window size and location could be controlled. These features were popular in commercial production environments, where complicated build and packaging processes were all controlled by elaborate scripts.
The shell had some important differences from its Unix counterparts. For instance, the classic Mac OS had nothing comparable to Unix fork(), so MPW tools were effectively called as subroutines of the shell; only one could be running at any one time, and tools could not themselves run other tools. These limitations were the inspiration for the MacRelix project, a 'Unix-like system' for classic Mac OS.
Look and feel
Functionally, a worksheet is a cross between a text editor document and an xterm window. Each worksheet window is persistently bound to a file. The user may type anything anywhere in the window, including commands, which can be executed via the keyboard's Enter key; command output appears at the insertion point. Unlike an xterm window, an MPW worksheet is always in visual editing mode and can be freely reorganized by its user. Hence a worksheet can be purely a command script or purely a text document or a mixture of the two—an integrated document describing the history, maintenance procedures and test results of a software project. The commercial BBEdit text editor retains a feature it calls 'shell worksheets' on Mac OS X. The Emacs text editor provides shell buffers, a similar feature that works across platforms.
MPW included a version of make. Its syntax was conceptually similar to that of Unix make, but the MacRomanlong f character to indicate dependencies. More significantly, since the limitations of the shell precluded the make program from running tools itself, it had to work by composing a script of compile/link actions to be run, then delivering that to the shell for execution. While this was good enough most of the time, it precluded makefiles that could make on-the-fly decisions based on the results of a previous action.
Although not implemented as MPW tools, the package also came with several source-level debuggers through its history; SourceBug and SADE (Symbolic Application Debugging Environment) were used on MC680x0 systems, while the Power Mac Debugger (known during development as R2Db) provided both local and remote debugging services for PowerPC systems, the latter by using a server program known as a 'debugger nub' on the computer being debugged.
Writing MPW tools
MPW included a set of standard C libraries sufficient for developers to build their own MPW tools. Many Unix utilities could be ported with little change. One point of difficulty was the Mac OS newline convention, which was different from Unix. Another was the pathname separator, ':' in Mac OS, but many Unix utilities assumed '/'. Many Unix utilities also assumed pathnames would not have embedded spaces, a common practice on Macs.
For a number of years, the GNU toolchain included portability support for MPW as part of libiberty. This was used to support MPW-hosted cross-compilers used by General Magic and several other developers.
MPW was started in late 1985 by Rick Meyers, Jeff Parrish, and Dan Smith (now Dan Keller). It was going to be called the Macintosh Programmer's System, or MPS. (Notice that coincidentally the three last names start with MPS.) 'MPS ' has always been the creator signature of the MPW Shell as a result of this. Since MPW was to be the successor to the Lisa Workshop, they decided to rename it the Macintosh Programmer's Workshop. Before the arrival of MPW, Mac applications had to be cross-developed on a Lisa.
The MPW Pascal compiler is descended from the Lisa Pascal compiler. Apple's Larry Tesler worked with Niklaus Wirth to come up with Object Pascal extensions which Ken Doyle incorporated in one of the last versions of the Lisa Pascal compiler. This enabled MacApp.
Early contributors included Rick Meyers (project lead and MPW Shell command interpreter), Jeff Parrish (MPW Shell editor), Dan Smith (MPW Shell commands), Ira Ruben (assembler and many of the tools including Backup, PasMat, and more), Fred Forsman (Make, Print, SADE, and assembler macro processor), Al Hoffman (Pascal compiler) Roger Lawrence (Pascal and C compilers, including the error messages), Ken Friedenbach (linker), Johan Strandberg (Rez, DeRez, RezDet), Steve Hartwell (C libraries), and Dan Allen (MacsBug, editor). The Apple Numerics Group also contributed math libraries.
MPW 1.0 was completed on September 24, 1986. A shell memory leak was fixed on October 10, 1986, and MPW 1.0.1 was born. MPW 2.0 was completed on July 20, 1987, and MPW 3.0 was done November 30, 1988. MPW 3.1, 3.2, and 3.3 came in the next few years. MPW 3.4 was completed July 14, 1995, and MPW 3.5 was done December 17, 1999. MPW 3.6 was under development when work was halted in late 2001.
During MPW's twilight years, Greg Branche supported MPW unofficially through the Apple MPW-dev mailing list. The list, and the lists.apple.com server that hosted it, was planned to be shut down January 17, 2014, a decision that was later reversed.
MPW can still be used to develop for Mac OS X, but support is limited to Carbon applications for PowerPC-based computers. To develop Mac OS X applications based on other technologies, one must use either Xcode or another OS X-compatible development environment. MPW also included a version control system called Projector; this has been superseded by modern version control systems and is no longer supported in Mac OS X.
- ^Webster, Bruce (February 1986). 'Programming Tool and the Atari ST'. BYTE. p. 331. Retrieved 9 May 2015.
- ^'Re: [Humor ] Old MPW C error messages'. Archived from the original on 2014-05-28. Retrieved 2014-05-27.
- ^MPW C Error Messages, May 15, 1994 - Robert Lentz
- ^'Re: Will the last one to leave please turn off the lights?'. Archived from the original on 2014-05-28. Retrieved 2014-05-27.
- ^'MacRelix Origins'.
- ^Short for RISC 2-machine Debugger; http://www.mactech.com/articles/develop/issue_17/Falk_Topping_final.html
- ^'Will the last one to leave please turn off the lights?'. Archived from the original on 2014-05-28. Retrieved 2014-05-27.
- ^'Reprieve!'. Archived from the original on 2014-02-14. Retrieved 2014-05-27.
- Official MPW website at the Wayback Machine (archived May 14, 2011)
- MPW 3.5 Download from Apple FTP Mirror & Updates
Shaping the future by understanding our past
I'm constantly busy shaping the future, exploring innovations, working on new ideas. But to accomplish all of this I also need to understand our past, where we came from, how it all started. It is then so much easier to see the big picture and many of the underlying details of the otherwise unknown and uncertain future.
This is even more true for application development. In a period of Functional Programming, Machine Learning and AI, still under the hood it all goes down to pure machine code. A mere sequence of zeroes and ones organized in words and made human readable thanks to assembler pseudo codes.
CPU gets every year faster, bigger in capacity, smaller in size, but.. the internal structure and modus operandi is basically still the same as 50 years ago
Evolution of Intel CPU vs. no-evolution of the instruction set:
Even the most advanced technology as Blockchain is deeply based on Assembly. On the Ethereum network GAS costs of Smart Contracts are visibly calculated based on which machine codes is being executed!
As you see unless a breakthrough in the way CPU internally works.. a real revolution in Machine Learning or even AI will remain just a chimera. But this is a different story.
Assembler on a Mac
Guess my surprise when I actually discovered that I could still program in Assembler using my newest MacBook Pro !
Yeaaah.. you can build, debug and run machine code programs right from your Mac!
Complete source code and some tutorials at my GitHub page: github.com/gaetanocausio
Well, first you need to install the proper tools. Open the terminal application and enter the ld command. If you get a popup warning like the print-screen below, then the tools are not yet installed, simply confirm by clicking on 'Install' (no need to get Xcode).
Now we are ready to try our first assembly program. Open a text editor, copy and paste code below and save it as.. guess what? HelloWorld.s
Mac Os X Latest
To be able to run an assembly program we need first to create an executable. This is a two step process. First you compile your source code by using the as command line tool, this will produce an intermediate object code that would need to be linked via the ld tool in the second step. The linker will make use of system libraries and resolve all references in actual addresses so to create the actual executable. See example below:
For macOS Mojave 10.14 use these parameters while linking: Canon netspot device installer for mac.
But as developers we know very well that debugging is an important aspect of application development and for assembly it is even more crucial. To debug an assembly program simply use the lldb command in terminal as shown below:
TIP: After executing the run command in lldb, try entering the gui command (lowercase).. it will start a GUI debug editor like in the cover image on this post!
Diving even deeper in assembly
Let's have a look on how parameters are passed from command line while discovering the similarities with the C language. In assembly the stack has an important role when passing control by means of a call statement. It points to 3 addresses:
Chrome For Mac Os X
Don't be confused with the third address, it's a bit tricky: it actually does not point to the parameters themselves, but to two more addresses, the first one is the location of the program name, while the second finally points to an array with the parameters:
It should all become clear with an example, when starting a program you have:
Assembler Mac Os X Tutorial
Tips and nice to know
Mac Os X 10.13
- Assembler on a Mac is slightly different than on a Unix or a PC. Therefore source code from other systems may not compile correctly on a Mac.
- The Stack Pointer register needs to be aligned to 16-byte boundary prior of performing a call. Failing to do so will lead to a segment address exception.
- Registers are name based on the architecture used, so the Accumulator register is named AX on a 16bit architecture, EAX for 32bit and RAX for 64bit.
- The full Apple reference to Mac OS X Assembler can be found here.