Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

PowerPC Assembly Language

timothy posted more than 12 years ago | from the picking-apart-ppc dept.

Apple 35

Josh Aas writes: "I've been looking for a way to learn PowerPC assembly language for a while now. My search for books only led to extremely out-of-date publications, and the whole ordeal was generally frustrating. I was amazed at the lack of documentation. Even Motorola and IBM's documentation resources (on the web) were lacking anything of use to me. However, it turns out that Apple provides a pretty good free tutorial on the subject. It's tailored for coding in Mac OS X, but I imagine it would be just as useful in any PowerPC environment. For some reason it includes instructions for the Intel architecture. Perhaps this has to do with the fact that Darwin runs on x86 as well."

Sorry! There are no comments related to the filter you selected.

And .... (0)

Anonymous Coward | more than 12 years ago | (#2581593)

... your point is???

Change? (0)

Anonymous Coward | more than 12 years ago | (#2581602)

out-of-date publications

Has the instruction set changed that much?

RISC (1)

wrt (530301) | more than 12 years ago | (#2582013)


Its RISC, so is there a point in programming at such a low level? I'd think that compilers these days make all but the most extremely obscure optimizations pointless. And that privilege might be reserved for the people who designed the architecture.

Re:RISC (1)

p3d0 (42270) | more than 12 years ago | (#2583215)

Assuming you're not a troll, but really are that confused...

Not everyone writes application software using Visual Basic and ActiveX. For example, what about the people who write the compilers? Anyway, optimization is not a "solved problem" as most people think it is, and hand-coded assembler is still undoubtedly superior in some cases.

Ask me why you need to know assembly after you've written a JVM (without a JIT even) that needs to achieve respectable performance. You'd have to be a better man than I to do that without peeking at the assembly code your compiler generates.

Re:RISC (0)

Anonymous Coward | more than 12 years ago | (#2583567)

Well, first, I would pick a virtual machine that wasn't designed to be a pain in the ass to optimize.

There is plenty of research into the subject that has been available for years before the first JVM was written, the only explanation I can come up with is that Javasoft is staffed entirely with morons.

Re:RISC (0)

Anonymous Coward | more than 12 years ago | (#2585539)

How about embedded applications? I had to learn PowerPC assembler for this very reason -- to write the boot code which configured the CPU and core peripherals (so that a commercial RTOS could then boot), and to do low-level flash chip programming (although we later re-wrote that in C).

You *can't* use C code (or most other 'high level' languages) when the RAM isn't even configured yet. We had to first get the SDRAM controller going, before we could even use the stack.
And how about when the hardware and software can't be trusted? (Think embedded systems-in-development again). Low-level RAM test routines, etc.

Re:RISC (0)

Anonymous Coward | more than 12 years ago | (#2595596)

Yes. A friend of mine wrote an emulator. Rewriting the core in PPC asm resulted in a significant speed jump. He rewrote some of the video routines in PPC asm, but only got a ~5% speed increase though, so maintainability won out.

Most compilers are good enough that asm coding isn't necessary, except in critical regions. But knowing asm is good to better understand how a computer works, how a compiler works, and to verify the compiler output is correct.

Re:RISC (1)

epepke (462220) | more than 12 years ago | (#2633293)

I've done some of this. It's really hard to make code so tight that you get better than a 5% speed improvement.

There is some value, however, when doing intricate floating-point code, especially when you can get control over the rounding conventions. It's also good for encryption code.

Is there a question in that? (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2582136)

Doesn't really matter if there is, since this didn't make the front page and all you'll get are "FIRST POST" responses.

PPC Altivec assembly information (3, Informative)

statusbar (314703) | more than 12 years ago | (#2582496)

Is available at here [altivec.org]

--jeff

The real use of assembly (5, Informative)

Snowfox (34467) | more than 12 years ago | (#2582656)

To those asking "why?" ...

The real use of learning assembly is to validate your compiler output. It's rare to want to code much from the ground up in assembly anymore, save hardware-banging code, but knowing assembly still makes all the difference.

Yes, most compilers will perform 1,001 optimizations, but the final bit of optimization you can eck out demands that you profile, examine the hot points, and replace them with assembly or restructure your C with a good idea of the code you really want it to generate.

You'll still find things that the compiler engineers haven't thought of, or were lazy about implementing, or operations which implement unneccessary logic/precision.

For example, sometimes it's best to hoist an expensive calculation -into- a loop because it fits where the processor otherwise stalls, but most compilers take the opposite approach. It's tough to force a C compiler to do this, because most want to hoist code -out- of loops when possible, assuming it's cheapest.

Dependency on non-native signedness, float format or type sizes can mean that shifts, transcendental math, type conversion, etc is being done in software when a single opcode is what you expected.

Understanding the code will tell you if something unusual is happening, such as non-native sized bools or less than optimal variables being turned into register variables.

Some operations are simply not available to the C-only programmer. Subsequent lookups to sin/cos operations can be combined into a single opcode, but I've yet to see it done by any compiler. It's only available in assembly.

The PowerPC offers a rough inverse/division approximation which is faster than a real divide, and is good enough for operations only requiring low precision or an approximation... also completely inaccessible to C code.

Knowing a variable is guaranteed to be within a certain range or of a fixed set of values at a certain point can let you get away with all kinds of murderous assumptions which it's impossible to express in C.

That said, I haven't seen a single PPC assembler reference that was half as good as just looking at the code. Look at code, look at a lot of code, and past that, just look at system implementors' documentation. x86 through Pentium III aside, most current assembler books are just fluff, are wrong about half the pipelining, omit a million useful optimzations and don't cover the real story at all. It's really gotten to the point where the only real way to learn is by doing and doing and doing.

Re:The real use of assembly (1)

kilrogg (119108) | more than 12 years ago | (#2583052)

Asking why you should learn assembly when you have higher level languages is like asking why you should bother to learn how to do multiplication when you have calculators.

Assembly shows you how your CPU does stuff at a much more basic level (e.g. what does the CPU really do with pointers? how does it do a for loop? How are signed numbers different from unsigned? etc). IMHO, every programmer should have taken at least one assembly course in their teachings. Even if they never program in assembly again, the indirect knowledge gained is very valuable.

Re: A whole different reason (2)

CMiYC (6473) | more than 12 years ago | (#2585465)

A completely different reason for wanting know Assembly language is not related to software. If you are a hardware design engineer, Assembly Language can be invaluable. I work for a company that makes Logic Analzyers and the most popular embedded processors is the PowerPC family. Our Logic Analyzers have a built in inverse assembler. Many Many times hardware engineers will look at the IA to determine what was going on, on the bus. Granted, they don't care what C instructions were being executed. They want to know, at the roots, what was the processor doing.

I think its very unlikely nowadays someone would write a computer application in assembly laungage. It would take way to long. But in the embedded world there are tons of reasons to know assembly. At the very least, everyone should know how to read it....

Re:The real use of assembly (1)

mkramer (25004) | more than 12 years ago | (#2586145)

As someone who works almost exclusively in PowerPC assembly, I notice a very large software development market that relies heavily on assembly programming that no one has mentioned. In embedded development, the developer works much closer to the hardware than in other markets.... While embedded operating systems provide the abstraction to allow application programming, almost every new piece of hardware needs porting work. The bootrom is obviously best written in assembly, as are many of the low-level functions the OS requires.

In the related field of Built-In Test software (Self-Test, Operational Ready Tests, On-Board Diagnostics, whatever you want to call them), there is also a high dependency on knowing exactly what the processor (and bridges) are doing and what their exact timing is. So that is another area that demands assembly knowledge. Especially if you're writing tests for the processor itself.

Not to mention, anyone working on compilers or operating systems in general will need the assembly and architectural knowledge.

GameCube (PPC) out today (0)

Anonymous Coward | more than 12 years ago | (#2582945)

Kind of interesting that this was posted on the same day as Nintendo's GameCube release in north america, which will be powered by a IBM's Gekko, a customized G3 (with new instructions specific for game development, and proprietary onboard memory/cache).

I was a mac fan in the early 90s - I haven't paid attention very much since the mid 90s, but this would definately get me interested in buying one, now (or obtaining an OSX/Darwin shell ;-) - to learn PPC assembly. I'd like to get into game development and what better a way! :-)

Here's hoping the gamecube dev kit software can be obtained on morheus...

Well... (0)

Anonymous Coward | more than 12 years ago | (#2583378)

`gcc -S' is a pretty good place to start. I remember when I was writing my Intel assembly intepreter (for my sophmore assembly class, mind you. No idea how to parse or anything like that. Then again my professor for that class was the semi-imfamous Victor Yodaiken; but I digress.) `gcc' and `objdump' were invaluable for figuring out even the nastiest of intracacies of that overblown calculator, and I imagine that they would be as useful as the first and fastest reference to any processor that they run on...

PowerPC Documentation from Motorola (4, Informative)

Strype (43887) | more than 12 years ago | (#2584094)

I'm working on an embedded PowerPC 603e and was able to find some descent documentation on the 32-bit PowerPC instruction set in general from Motorola's home page. I know you said you checked there, but I had a difficult time tracking it down myself. So in case you missed it, the name of the document is PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors [motorola.com] . I ordered a printed copy from their literature center, and a week later I got a nice little green book that has already proven to be indespensable.

Re:PowerPC Documentation from Motorola (2, Interesting)

buserror (115301) | more than 12 years ago | (#2584835)

I agree that the Moto doc is quite useful, having a reference on all the opcodes proves indispensable as soon as you need to *write* some code.

If you just want a few lines of assembly, write a small C function that does roughtly what you want, disassemble it and 'adopt' the generated assembly into your own piece.

One very useful notation in codewarrior is that you can specify the register to use for parameters, it helps a lot when doing those things:
long blah(long p1 : __r10, long p2 : __r11) : __r4 {..... }

For patching stuff, I've found that using CodeWarrior assembly functions is extremely useful too. As well as for getting the hex value for opcodes from the disassembled output, saves a trip to the reference book.

Re:PowerPC Documentation from Motorola (0)

Anonymous Coward | more than 12 years ago | (#2591482)

Good idea! However sometimes the compiler will not even use the best instruction for the problem (e.g. because it wasn't built into the code generator). In that case you will have working assembly code but not the opmimum code. Take for example manipulation of single bits on x86. To code this in C you will need something like c = (c && mask) || bit which most compilers will translate to an AND and an OR instrction instead of a single bit set instruction.

Re:PowerPC Documentation from Motorola (1)

e4liberty (537089) | more than 12 years ago | (#2587694)

The little green book is indispensible, along with the User's Manual for the specific processor.

Another great book from IBM is the PowerPC Compiler Writer's Guide [ibm.com] . It is available in pdf format on line, or IBM will ship you a copy.

e

you are so cute (0)

Anonymous Coward | more than 12 years ago | (#2584627)

You'd be dead after 2 days on a ps2 devkit.
You got old books, so what ?
Be like your ancestors, get busy coding anyway.
No need to come crying on Slashdot, most of the people here are only talkers anyway.

Code !

A few good links (2, Informative)

Anonymous Coward | more than 12 years ago | (#2585612)

PowerPC [motorola.com]

Technical Library [ibm.com]

PowerPC FAQ [motorola.com]

Lightsoft: Beginners Guide to PowerPC Assembly Language [lightsoft.co.uk]

March 95 - Balance of Power: Introducing PowerPC Assembly Language [mactech.com]

PowerPc Architecture [mactech.com]

PowerPC Library [mot.com]

The Metroworks Code Warrior documentation also has some helpful stuff. I found a copy online a while ago, but it's gone now.

x86 instructions (3, Funny)

selectspec (74651) | more than 12 years ago | (#2585782)

For some reason it includes instructions for the Intel architecture

I thought the Power PC was x86 compatible.

Re:x86 instructions (1)

morcheeba (260908) | more than 12 years ago | (#2585824)

nope, it's not. There are software emulators, just like apple's emulator to run old 68k code, but it's all software.

Re:x86 instructions (1)

karlm (158591) | more than 12 years ago | (#2586059)

If that were the case, you'd almost definately see x86 linux binaries running directly on PPC Linux. The boot sequence, memory management, etc. would necessitate dramatic kernel differences, but there would be userland binary compatability.


PPC has M68k emulation right on the die, at least the older chips did. That's probably what you're thinking of. This allowed MacOS to slowly migrate to PPC native code. M68k is CISC architecturre. x86 is a CISC architecture. PPC is a RISC architecture.


<aside>
It's good to see Intel's flagship CPU running a VLIW instruction set, with x86 emulation on die.
We've been dragging arround the legacy x86 instruction set for a few decades now. x86 instructions are pretty compact, but they have a serious lack of registers. There's a lot of trickery going on in the Athlon XP and P4 in order to overcome the instruction set's weaknesses. Less trickery = less power consumption and/or better cost/performance. Personally, I'd like to see CPUs with only 2 or 3 ALUs per "CPU" and "SMP on a chip" since it's hard to average more than 2.5 issues per clock cycle. 90% of the time you've got a few ALUs that you've paid for just sitting there. Unfortunately, most of the bachmarks and apps out there are a single threaded single process, so you wouldn't see much of a performance increase until people started writing multithreaded apps. Of course, most server apps use a pool of processes to handle requests, or fork off a new process for each new request. Servers and multi-user machines would imediately see an increase in performance. VLIW is designed to really cut down on idle ALUs by making multiple issues explicit in the instruction set and moving all of the trickery into the compiler. VLIW is kind of like a RISC revival. It's about getting back to simpler chips, made possible by better compilers and higher appearent memory bandwidth.</aside>

Re:x86 instructions (1)

mkramer (25004) | more than 12 years ago | (#2586164)

I know that from the PowerPC 603 core onward, there was no support for non-native isntruction sets. I'm rather hesitant to believe otherwise abotu earlier chips, too. I always thought that the early PoweRPC MacOS support for 68K code was entirely software-based. Maybe I'm wrong, though. Any idea what chips ahd the M68K core?

Re:x86 instructions (1)

entrigant (233266) | more than 12 years ago | (#2586169)

"x86 instructions are pretty compact, but they have a serious lack of registers."

You'll have to excuse my uncalled for amount of obvious thinking... but did some supreme power ever forbid adding more registers or smthn? It would be entirely possible (and most likely pretty easy tho I am not an engineer) to just add 8 or so new registers while maintaining backwards compatibility... ?

You will also have to excuse my cynicism... I just wait patiently for the day for someone to give me a good reason why x86 needs to be replaced. Not an easily solved half assed excuse like lack of registers.

Re:x86 instructions (2, Interesting)

karlm (158591) | more than 12 years ago | (#2587069)

You would have to re-engineer the instruction set in order to add more registers. You would break backward compatability or make a totally new set of really long instructions that use the new registers. Both solutions have no advantage if you're still going to call it x86.

It's just a really klugy instruction set. Floating point was added after the fact. IIRC, you have to multiply something in EAX by something pointed to by ESX or some such. This means you end up doing lots of needless loads and stores and loads and stores if, for instance, you're dealing with even a small system of polynomial equations.


Your modern x86 CPUs can do "register aliasing" to try and overcome some of this register thrashing and to allow more parallelism, but aliasing circitry takes up realistate.


Allowing self-modifying code is also a pain in the ass (PPC simply does not allow it) if you're going to try and run the instruction set non-natively (such as on the P4 core). Self-modifying code will thrash the P4's "translation cache". Memory pages have three permissions (read, write, execute) just like Unix files. However, several of the eight combinations are not allowed by the instruction set. This causes some minor security problems. (I forget which modes cannot be set. You can argue that some of them are useless as the x86 architects did, but there are some non-obvious situations where you might want some of the stranger modes.)


People also complain that the x86 has too many addressing modes. IMHO, they should design instruction sets to be simple and allow for simple emulation. They know that they'll be emulating it on a more advanced core later down the line or shipping with an emulator in the BIOS or some such, so they might as well make their lives easier. IBM had the right idea with OS/390. Basically they designed the hardware and low level system such that the user never saw any code running on bare metal. The "OS" that the user saw was running in something like VMWare. Linux for S/390 runs in an OS/390 partition (basically a virtual machine) and never on the bare CPU. This has lots of advantages for security, stability, modularity, isolation, and maintainability, as well as ease of migration on to the next generation.



There are reasons Intel is migrating from x86 on the high-end CPUs. Don't get me wrong, I'm a big AMD fan, but I think sledgehammer is going in the wrong direction. I woould much prefer that AMD made a PPC, SPARC, ARM, or MIPS instruction set cpu with on-die x86 emulation. We've been doing x86 emulation on a RISC core since the original Pentium chip. It wouldn't take much realistate to expose the RISC or VLIW instruction set as well.

More simply (2, Interesting)

karlm (158591) | more than 12 years ago | (#2587369)

More simply, instuction sets are designed based on a set of asumptions. The x86 instruction set was based on a set of assumptions that was true 20 years ago. x86 assumes that memory is expensive and compilers don't optimize well, so it's got lots of nifty little optimized instructions for doing common (and not so common) tasks and uses variable length instructions to make the code more compact.


RISK instruction sets assume you don't mind having slightly larger code segmets if it means that most of your instructions execute in one clock cycle and you can up your clock rate (this is why the pentium family uses RISC cores). It also assumes you don't want to pay in transistors (and power and heat) for rarely used instructions. It also assumes you have compilers that a good enough so that you don't pay too high a penalty for not having those scan opcodes, having to work with only a couple of addressing modes, etc.


VLIW takes this one step further. You don't mind increasing your code size because it means that your compiler has lots of time (comparatively) to figure out how to do multiple simultaneous issues in order to maximize your performance per transistor by explicity putting each issue into the verly long instruction. This assumes that you have very smart compilers. Unfortunately, it also means that your instructions are big. If clock multipliers continue to climb, you may see VLIW instruction sets, but decompressors on the die in order to increase the appearent memory bandwidth.


Note that this progression in instruction sets represents a progressive moving of certain aspects of the CPU somplexity from the CPU core into the compiler. This allows the limited die realestate to be used for more ALUs, more Cache, smarter branch prediction, "SMP on a chip", etc. while continuing to allow the price of CPUs to fall.


You can do on-chip emulation of the legacy insstruction sets (like on the P4 and even the Itanium), but it's baggage you have to drag arround even when running your native code. Software emulation of the legacy hardware seems more appropriate. If we all switched to some VILW CPUs now, in another 3 years (being pessimistic), Bochs (or another emulator) running on those CPUs would run the legacy code as fast as today's machines, and would run native code much faster.

Re:x86 instructions (0)

Anonymous Coward | more than 12 years ago | (#2595620)

PPCs never had a 68k emulator built in. Early (601) PPCs had support for the full POWER instruction set (basically a few extra instructions), but that support was removed by the 603.

Re:x86 instructions (1)

angel'o'sphere (80593) | more than 12 years ago | (#2600787)

The 68k "emulation" on MACs with PowerPC was allways a software emulation.

The only thing which is on the die is switchable big or little endian format.

There was never a on the die x86 or 68k processor.

However, the later software emulations of 68k on PowerPC outperformed the original 68040 MACs.

Regards,
angel'o'sphere

Re:x86 instructions (2)

Rogerborg (306625) | more than 12 years ago | (#2606518)

  • I thought the Power PC was x86 compatible.

Like horses and donkeys, but they invariably produce a sterile hybrid called the Transmeta.

(slightly offtopic) - Excellent assembly book (1)

Jormundgard (260749) | more than 12 years ago | (#2586160)

I wish I knew more about the PowerPC, but I noticed that the discussion has taken a turn to the usefulness of assembly. Someone also mentioned that there are no good assembly books. I totally agree - almost none teach effective techniques, but instead just explain the instructions (you're lucky to see a jump table explained). But Randall Hyde has an excellent online textbook [ucr.edu] for the x86 (mainly focusing on the older Intels). It does stress technique, and doesn't bog you down with too much syntax.

Just an added use of assembly---it's pretty essential in programming the older consoles, although probably not these days :). I don't know about the Game Boy Advance (I heard that a C compiler was planned in the pre-release days), but one definitly wrote in assembly for the older Game Boys.

Free docs from Motorola (1)

macrom (537566) | more than 12 years ago | (#2587317)

For what it's worth, I was able to call Motorola earlier in the year and get a box of PPC documentation sent to my office, all free of charge. Specs on the 74XX series (7450's aren't covered in my docs), details on the instructions, Altivec highlights, you name it. I got the number off of their PPC site (somewhere from http://www.mot.com) -- it should be a toll-free number for those in the US.

Just a word of warning, though -- the docs AREN'T tutorial-style. If you can pick up PPC assembler based on your previous knowledge of another architecture, then these documents should benefit you nicely.

greg
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?