[cynistar]

Hey friends - Here is a sort of vague question for you regarding OS X -

Has anybody tried messing around with PPC Assembly in OS X - I really want to see how far into the guts of my little iMac I can get - I want to take direct control of the hardware and do weird stuff if I can - Anybody tried this kind of thing yet?

thansk///

[davecom]

Just posting to keep this alive as I am interested in this too.

------------------
Think Different.

[sadie]

I've never done this, but I'd guess it's the same as with any BSD - even written in assembly, there are strict limits on what the kernel allows each program to do. You won't find a lot you can do in assembly that you can't do with Objective-C (except being faster, of course).

However, you will find a lot you can do with the various higher-level interfaces available for communication between programs and parts of the system. Spawning Terminal apps, for example, gives you a lot of freedom.

You know, if you *really* want to fiddle, try the Open Firmware. At startup, hold down ( option, command, o, f ). Instructions are at http://developer.apple.com/technotes/tn/tn1061.html

[Angus_D]

Yeah, as was said you can't go any lower level by using assembly, but optimized assembly is often faster than optimized C.

There are lots of private frameworks for you to fiddle with, especially if you use class-dump to extract the interfaces

You can, of course, go lower level by entering kernel space and writing a kernel extension...

[cynistar]

Yeah - thats what I was thinking - Messing with KEXTs - I really wanna 'talk' to the hardware without hinderance.

I'm wondering how hard it would be to totally take control of the machine - Say - to make a super stable music app or something...

[Dalgo]

Unless you modify the kernel, you can't take total control of the machine. I am not an assembly guru but I have been slowly, trying to learn assembly. In my opinion, PowerPC Assembly looks easier than 68k assembly because there are fewer instructions to memorize but, on the other hand, there are also more steps in doing stuff. The major stumbling block that I have run into is incorporating assembly in with C/C++/Objective C. You can use something like _asm("type assembly here") in order to put an assembly statement directly into C code but I don't know how to access data that I declared in C. You can call C functions from within assembly, I don't remember how but it isn't all that hard.

Here is one way to see the code that the compiler generates. Write a short program in c that only takes up one file. Then, on the command line compile it like this:
cc -S myFile.c
It will generate a myFile.s which is an assembly file. You can then read that and see what the compiler generated. Also, remember that you can specify different optimizations for example, -O3 is highest level of optimization. Example:
cc -S -O3 myFile.c
I know that you can also generate assembly output for compiles of multiple files but I do not know how.
I'm not sure if the compiler is very efficient or not. It always looks like it's branching and using the stack when it doesn't need to but I'm going to have to learn more assembly in order to really see what's going on.

[Edit]
Oh yea, if you want to talk more closely with the hardware, I think that it'd be a better idea to invest time in learning IOKit instead of assembly, or at least before assembly. Why go insane trying to figure out an assembly interface when you already have one in C?

[This message has been edited by Dalgo (edited 05-13-2001).]

[cynistar]

Because I want ZERO layers of abstraction in my way - I want to hack this like the old 68k amiga hackers used to do - total control - not some 'official apple approved' IOKit...

[battlej]

admirable, but I'd start with the IOkit, if I were you... at least that way, you'll see what you can and can't do. then go to assembler.

as far as what assembler is available, osx comes with a fairly complete gnu toolchain, which includes the GNU assembler, with some optimizations for altivec from apple.

I'd start with a good PowerPC assembly book, if I were you.

g'luck

[gralem]

Do you guys recognize your illness? Professional counselling can provide a very helpful hand in your sick sick cases!



---gralem

[Angus_D]

Originally posted by cynistar:
Because I want ZERO layers of abstraction in my way - I want to hack this like the old 68k amiga hackers used to do - total control - not some 'official apple approved' IOKit...

perhaps it's "apple approved" because it makes it:
1) easier
2) harder to screw up
3) less pointless

you don't need to even go as low as IOKit. Use CoreAudio. Would you like to explain just why you plan on going and talking to the hardware directly? Not only will this cause problems because it will only run on computers almost identical to the one you're using, but it will also be a hell of a thing to debug, and you're going so low level that you're not going to be able to do it on OS X (where I'm pretty sure everything goes through Mach, and even going as low as mach from carbon/cocoa apps can make things screw up).

If you really want to talk to hardware directly, go write your own OS.

[cynistar]

Actually that is a good observation - Why would I even *want* to get that much low level control of the hardware? Well, I am thinking of writing a sort of 'solid state' electronic music program - one where there is NOTHING other than the software itself doing its thing... Not the finder, not a scheduler nothing -

And I am in fact only thinking about doing this on a specific rev of iMac or maybe iBook - because they can be had cheap nowadays and if I turn one into a depdnable and stable noise maker it will be something I can use in live entertainment ...

It has always been a dream of mine for somebody to write a sort of 'MUSIC ONLY' OS where I put in a CD and the machine boots off of the CD and is 'taken over' by this Music OS with nothing else taking any processor time or causing conflicts - Of course, I'd still want access to storage (hard drive) but the guts of this system would be kept on a CD...

anyway - that's what I'm thinking about...

[Since EBCDIC]

What you're talking about is writing a simple operating system. It can be done, rather easily too. I suggest that you check out books about Minix, for example.

The reason that most folks don't do this (and why few will understand what it is you're proposing to do) is because there's such a great advantage in using the resources programmed by the OS designers.

You could boot Mac OS X in single-user mode, use the command-line interface, and you're pretty close to the "cold iron" of the hardware but with lots of resources and libraries at your disposal.

------------------
Since EBCDIC
Make every post count!

[sadie]

Since EBCDIC
You could boot Mac OS X in single-user mode, use the command-line interface, and you're pretty close to the "cold iron" of the hardware but with lots of resources and libraries at your disposal.

Or just use Darwin. Or BSD.

[Angus_D]

Originally posted by Since EBCDIC:
You could boot Mac OS X in single-user mode, use the command-line interface, and you're pretty close to the "cold iron" of the hardware but with lots of resources and libraries at your disposal.

You're really no closer than running OS X in normal mode... You're still quite a few layers away from the hardware. There are fewer processes running, but that's about it.

If you really want to write an OS, then good luck to you. To me it sounds incredibly stupid, and a lot more work than it needs to be. But hey, if you want to write device drivers for mundane things like IDE hard drives, it's your choice

[Dalgo]

If you wish to supplement C/C++/Objective C with assembly in OS X, then when you want to put in some assembly statements do it like this: Suppose that you want to, for some reason, copy r3 ro r5, then say copy r3 to r7 also. Then, amidst your C code you could add this:

asm ("mr r5, r3\n"
"mr r7, r3");

viola, that's it... but there's one more thing that you might wish to do. Sometimes the compiler might get wise and decide that it doesn't like the assembly that you have added. In order to prevent the compiler from changing it, all you'd do it like this:

asm volatile ("mr r5, r3\n"
"mr r7, r3");

The volatile keyword keeps it from messing with your assembly. BTW, if you want to map variables in C directly into specific registers you do it in the declaration like this:

register float myFloat asm("f6");

This makes it such that myFloat lives in f6 during it's scope. Give up on writing a new OS and just use assembly to supplement your C/C++/Objective C.

[Angus_D]

This isn't what he wants to do. He wants to make sure that his code is the only code running so that there is no chance for bugs in other people's code. This is a common mentality, but he has taken it to the extreme. Anyways, if he really wants to write his own OS, this is completely offtopic for the OS X - Developer forum.

[parallax]

Moving this over to Developer.

Good luck, yer gonna need it.

[lgerbarg]

Originally posted by cynistar:
Because I want ZERO layers of abstraction in my way - I want to hack this like the old 68k amiga hackers used to do - total control - not some 'official apple approved' IOKit...

Two things here. First, what you are talking down does not necessarily involve asm. You can hit and manipulate memory addresses directly in other languages:

#define PPC_HW_ADDR (0x00000100)

int main(void)
{
PPC_HW_ADDR* = 0x02;
}

directly twiddles an address. So this not really about assembly.

As for bypassing IOKit, don't try. You are far better off writing your own OS from scratch if that is want you want. In order to manipulate stuff like this from userland you need to hack the kernel to allow your program to access untranslated memory, and if you are doing anything intricate you will need to alter the interrupt vectors which will screw up everything in IOKit, included all PCI devices. So in other words you will have to manually control everything, at which point there is no sense in using OS X.

Louis

------------------
Louis Gerbarg
Darwin Developer

[SmileyDude]

Back to your idea about wanting to write a "'solid state' electronic music program"... what makes you think that writing this on top of an existing OS is a bad idea?

The OS is going to provide a number of services for you that you would have to reproduce -- IDE access (for your CD), video, sound, and more. Also, by having an OS, you could have an additional task running that would act as a watchdog for your application... if it dies (which it probally will), it gets automagically restarted.

Anyway, if you really want to build something like this with a minimal system, I would recommend taking the Linux or Darwin kernel, and building on that. I only say Linux, because it would seem to be the easier kernel to build on, and there is lot's of source code available. Darwin may be just as good, but with the Mach kernel, it's an additional layer between the hardware and your app.

Anyway, back to the Linux kernel... you would just set it up so that your application is the 'init' process for the system. You would boot off your CD, and as soon as the kernel was running, it would start your program.

I wouldn't worry about the overhead of running the scheduler on any modern machine... even with the lowest iBook, the overhead is going to be very low... heck, with any PPC it's going to be low.

Now, if you are after realtime response, you would need some changes, but there are plenty of realtime patches for Linux... I'm sure using those patches with Linux on a PPC would be loads easier than trying to write an app to the hardware.

Plus, if you are trying to write to the hardware on your own custom OS, you are going to have problems debugging the code. Using Linux or Darwin would allow you to use a LinuxPPC or OS X machine for development. Debugging problem solved.

So, to re-iterate, I would highly recommend against writing to the hardware... use one of the freely available kernels and build on top of it... unless you have some radical ideas that you want to play with in kernel space. But from the sounds of it, you just want optimal speed, when in reality, you don't even need it.


------------------
dennis

[cynistar]

Thanks to everyone for all the feedback so far -

Hmmm - I am really after response(real-time) and stability - Right now - among electronic music makers there is still a perception that using a computer for live performance is too risky - As opposed to using some 'hardware' sequencer box - Which is really just a simplified computer.

The idea is to go as lean as practically possible. It doesn't sound like writing ASM code from scratch is practically possible right now. But, if it were done, it certainly seems that the best thing to do would be to start with a simple Kernal - It is obvious that building the infrastructure to 'talk' directly to hardware from scratch would take much longer than writing the music creation App itself.

I think i will investigate a Darwin + Music OS combo - Mainly because the support that is forming in terms of people writing drivers, etc.

Although, if somebody could fill me in on this - I have heard that Darwins real-time ability blows right now - That is, if I wanted my music APP to hog all of the CPU, Darwin will not allow that - I may be phrasing the question wrong, but hopefully somebody will understand what I mean...

thanks!

Just as a note here... If you're after total control of the computer, you're never gonna get it in Mac OS X. Mac OS X's task scheduler (or whatever it's called) will cheerfully wrestle away control from your app whenever it feels like it. All (as far as athything you'll be using goes) OSs (at least the part we care about) gets lots of fun special privleges that normal apps **can't** have, such as deciding when any given task has had its fair share of CPU time. Welcome to the world of pre-emptive multitasking,

-Whisper

[SmileyDude]

If you do go the Darwin route, one easy way to insure that you get most of the CPU, is to not run other programs. Kill all the daemons, and only leave the ones that you need. Sure, the scheduler will awaken, but once it realises that it doesn't have any programs to switch to, it will let your program continue... which, actually, is what it would be doing most of the time anyway.

------------------
dennis

Go for it! (Easy for me to say; I have to work and like to eat.)

Another option is to implement in Forth. (Have a look at http://dec.bournemouth.ac.uk/forth/forth.html ). A class of Forth implementations are designed to be operating system _and_ application programming environment. And most Forths encourage incorporating as much or little assembly as you want.

The bad news is that it is a jaw-dropping amount of work. Probably your best bet is to start in Open Firmware (which is just a special purpose Forth for managing the boot process). I've never explored OF, but I know you can program it (define "words" in forth parlance). There is very little between you and the hardware at that point. Then you 'just' have to define exactly what you want the sound output to be, learn exactly how the sound harware works, write your code and test it. 'Course, OF is perfectly capable of locking up your Mac so it will never boot the MacOS again so you'll want to keep a couple of spare machines and/or NVRAMs around. But hey! Everybody needs a lifetime hobby!

Craig

[theolein]

I think you guys could use some help
fantasm is an asembly IDE for mac and AFAIK now works in OSX
heres the url: http://www.lightsoft.co.uk/Fantasm/fant.html

------------------
#ex-dotcom#
#job anyone?#