HLA and Intel Macs

[viktoras.d]

Hi! Is there a way to get assembly code output with HLA that could be compiled on MacOSX (Intel)? In general the topic of assembly on MacOSX seems quite cryptic  :dazzled:. Given that MacOSX is based on Unix and already goes Intel (x86, isn't it or I am wrong here?) nowadays, I guess at some point in future (?..) it should get much easier to create cross-platform apps with assembly for x86 architecture (MacOSX, Windows, Linux). Was GAS or FASM ever ported to MacOSX Intels? At least gcc and gfortran is already there and these used to be companions of GAS. Any good news on the topic?

All the best!
Viktoras

[Evenbit]

HLA doesn't support Intel Macs yet -- the Standard Library needs some modifications to handle the differences between Linux system calls and OS-X system calls.  If you feel up to it, you could try to make those modifications yourself.  Or, just use another tool.  Apple has ported NASM to its platform:

http://www.opensource.apple.com/darwinsource/Current/

http://developer.apple.com/documentation/DeveloperTools/nasm/nasmdoc1.html

Nathan.

[viktoras.d]

Thanks, Nathan!

Does anyone know if the HLA's standard library will use NASM as a "backend" on MacOSX and other x86 systems then? Or yet something else?

Viktoras

[Sevag.K]

The back end of HLA on the Mac will most likely be as.  None of the systems use NASM.  The current options are TASM (minimal), FASM, MASM and AS.  FASM is internally supported by HLA on Windows and Linux.

[Evenbit]

Thanks, Nathan!

Does anyone know if the HLA's standard library will use NASM as a "backend" on MacOSX and other x86 systems then? Or yet something else?

Viktoras

The choice of "backend assembler" is not the big issue when dealing with portability between operating systems.  The problem is that every OS has its unique API functions that application programmers use to do all the typical things (print words to the screen, read keyboard input, read & write to the HD, etc.. ) that programs need to do.  The HLA Standard Library was written to work with *only* Windows and Linux API -- if you want it to work with MacOSX, then you have to add the proper code to the library so that it understands the MacOSX API.

The information for the Windows API is here:
http://msdn2.microsoft.com/en-us/library/aa383749.aspx

The information for the Linux API is here:
http://asm.sourceforge.net/syscall.html

Do you know where the information for the Mac OS-X API is?

Nathan.

[viktoras.d]

Do you know where the information for the Mac OS-X API is?

some info on MacOSX assembly is here:
http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/ASMIntroduction/chapter_1_section_1.html

the next thing I know is that MacOSX system calls are derived from FreeBSD. And the only in-depth resource afaik  :red is a book MacOSX internals: A Systems Approach (http://safari.oreilly.com/0321278542)

Viktoras

[Evenbit]

Do you know where the information for the Mac OS-X API is?

some info on MacOSX assembly is here:
http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/ASMIntroduction/chapter_1_section_1.html

the next thing I know is that MacOSX system calls are derived from FreeBSD. And the only in-depth resource afaik  :red is a book MacOSX internals: A Systems Approach (http://safari.oreilly.com/0321278542)

Viktoras

Well, here are some links to BSD SysCall tutorials so you can see what is involved:

http://user.nj.net/~tms/hello.html
http://www.int80h.org/bsdasm/

Also, take a look at this thread:
http://www.masm32.com/board/index.php?topic=6433.0

Maybe you could try some of these and report back what works and what doesn't.

Nathan.

[Randall Hyde]

Hi! Is there a way to get assembly code output with HLA that could be compiled on MacOSX (Intel)?

Sure, tell HLA to emit GAS code (e.g., using the -sg command line parameter). You may then compile the output on the Mac (from the terminal window) using the as assembler (Gas).

Note that as the HLA stdlib has yet to be ported to the Mac, you cannot make any stdlib calls, and you can only compile units, not programs (which make stdlib calls). But you can link such code with C++ or other programs, or you can make all the low-level system calls yourself.

In general the topic of assembly on MacOSX seems quite cryptic  :dazzled:. Given that MacOSX is based on Unix and already goes Intel (x86, isn't it or I am wrong here?) nowadays, I guess at some point in future (?..) it should get much easier to create cross-platform apps with assembly for x86 architecture (MacOSX, Windows, Linux). Was GAS or FASM ever ported to MacOSX Intels?

Gas has always been there. I believe NASM is there. I do *not* believe there is a Mach-o output module for FASM, though.
The HLA port will use Gas as the back end.

At least gcc and gfortran is already there and these used to be companions of GAS. Any good news on the topic?

Gas is already there.

Porting the HLA *assembler* to the Mac is a straight-forward task.  Maybe a full day's worth of work (particularly given that I've already ported the compiler to FreeBSD). The real work involved is in porting the HLA stdlib to the Mac. That is the ultimate goal of current work on the HLA stdlib v2.x: to create an easy to port version of the stdlib and get it ported to FreeBSD and MacOSX.

Alas, the stdlib needs a little more loving care than just a couple of OS ports. Over the years it has grown rather "organically" and is in desparate need of refactoring. That's the current task being done. Once all the code is rewritten and cleaned up, the actual ports to FreeBSD and MacOSX should be fairly straight-forward. *Then* it will be practical to have HLA running on the Mac.

BTW, FWIW, I'm currently doing most of my HLA development on my Mac Book Pro using Parallels.  I'm also eyeing a Mac Pro Octo as a replacement for my main development PC at home, so I think you'll believe me when I say that getting HLA running on MacOSX is a fairly high priority for me.
hLater,
Randy Hyde

[stevenp]

Randall, this is great news to hear that you'll be porting HLA to Mac.

Considering the list of applications my work needs me to develop for them (a security one, for instance) I told them I need to develop some of the applications in assembly.  So I gave them a list of books I need and one of them is the The Art of Assembly Language (the other two are security and cryptography related.) 

I am absolutely excited to get learning HLA and have thought of doing it for quite a long time now.  :8)

BTW, from personal experience, would any of you tell me your thoughts on how comfortable you are in creating a full blown Window's app in HLA?  Or would you consider it too much work?  My understanding is the standard library included with HLA helps this considerably.

[Sevag.K]

The standard library won't be much help with the GUI portion of the application, it is a tremendous help for general assembly programming though.

I'm not comfortable creating full blown Windows apps in any language.  I think it's a flawed design.  However, it shouldn't be too hard if you are already familiar with the Windows API.  I've developed HIDE using HLA and the sources are available if you want to see an example of a medium level Windows app.

[stevenp]

Thanks for the response!

I'm not comfortable creating full blown Windows apps in any language.  I think it's a flawed design. 

I'm sorry if I don't understand you correctly.  Windows apps have to be created in some language.  I know, I do it for a living.  Perhaps I don't understand what you mean?

However, it shouldn't be too hard if you are already familiar with the Windows API.  I've developed HIDE using HLA and the sources are available if you want to see an example of a medium level Windows app.

Did you find this difficult and time consuming to create (compared to other languages)?  I am really interested with your experience with HLA compared to other languages you may be familiar with since I am just about to learn it.

[viktoras.d]

Hi stevenp,

sharing my personal experience - i would not do any large project entirely in assembly as it would be too complex to maintain, fix bugs, etc... When I have to create a full-blown crossplatform (MacOSX, MS Windows, Linux) application with graphical user interface I use different tools to implement different layers of the software depending on what I need and where... For example, graphical user interfaces can be created with tools like Delphi/Kylix. Unfortunately it is not available on MacOSX, therefore my prefered tool is Revolution studio. Other suitable alternative I know is Tcl/Tk, or maybe Java (but then are you sure that the end user has the right JVM installed?..)

So I can create a full-blown database application in a few hours. But the price for the easiness of development and all the eye-candiness is a major loss of performance in certain places of the code. Well, it loads fast, you can process thousands of records in a database or flat file without noticing that it takes any time at all, etc, etc... But the real botleneck is processing large binary files like images, maps, data structures, data streams. Therefore when the performance is crucial when dealing with large amounts of data I have to switch to low level languages. Again the tools i use allow me to create external modules (libraries) in C/C++ and then use them as functions from within the development environment. But in some cases even C is not fast enough... I guess that's why most of us end up in an assembly forum like this.

Regards!
Viktoras

[stevenp]

Thanks for the reply!  Your answer makes perfect sense.

Incidently, I also own Revolution.  For cross-platform development it's great.

[Sevag.K]

Thanks for the response!

I'm not comfortable creating full blown Windows apps in any language.  I think it's a flawed design. 

I'm sorry if I don't understand you correctly.  Windows apps have to be created in some language.  I know, I do it for a living.  Perhaps I don't understand what you mean?

What I mean is that I don't like the Windows interface.  I've also dabbled with Java and wxWidgets and prefer those interfaces over Windows and x-Windows.

However, it shouldn't be too hard if you are already familiar with the Windows API.  I've developed HIDE using HLA and the sources are available if you want to see an example of a medium level Windows app.

Did you find this difficult and time consuming to create (compared to other languages)?  I am really interested with your experience with HLA compared to other languages you may be familiar with since I am just about to learn it.

I can't really answer that question since I learned programming with HLA.  I did (and do) dabble with Java, C, C++ after learning HLA and creating Windows apps in C/C++ is just as annoying as doing so with HLA :)  Of course, I never used those fancy IDEs that write applications for me.  If you use those on a regular basis, you will find GUI programming with assembly more tedious.

But.. Java is interpreted and Widgets produces bloated executables (plus I haven't been able to get it to work with HLA) so I have to grind it and stay with Windows until I get around to writing my own cross-platform GUI.  You can see my first attempt at that with my guilib (posted somewhere on this forum).

[Randall Hyde]

Randall, this is great news to hear that you'll be porting HLA to Mac.

And progress is being made. I just announced HLA stdlib v2.2 today. That takes care of all the platform independent code. Now I'm working on the platform specific code. Once I get it cleaned up for Windows (and Linux), I'll start the FreeBSD port. Presumably, as MacOSX is a variant of BSD, moving from FreeBSD to the Mac should be pretty easy.

BTW, from personal experience, would any of you tell me your thoughts on how comfortable you are in creating a full blown Window's app in HLA?  Or would you consider it too much work?  My understanding is the standard library included with HLA helps this considerably.

Well, I am currently working on a Tektronix terminal emulator for General Atomics (it's getting real hard to find Tek 4025 graphics terminals these days) and I'm writing that app in assembly as a test application to see if I dare do the reactor console rewrite in assembly.

The terminal emulator will run under Windows (the console software is going to run under Linux).

The HLA stdlib helps with a lot of the *kernel* stuff, but it provides nothing for the UI. That's going to be pure Win32 API code (in assembly) for me. Quite frankly, it's not that bad, but there is a big learning curve attached to this process.

Ultimately (long after the Mac port, and indeed, long after HLA v2.0 makes an appearance), I'd love to do an object-oriented GUI library that lets you write portable GUI apps for Windows, Linux, FreeBSD, and Mac OS. But that's just a dream at this point. A lot of work to do before seriously thinking about that.
hLater,
Randy Hyde