| Home | Forums | What's new | Resources | |
| Need a DSP assembler... |
| PyroMeistar - Jan 9, 2004 |
 |
vreuzon | Jan 10, 2004 | |||
Why do you want to use asm ?
I use "satourne dynarec" (the last version of the first satourne). | |||||
 |
antime | Jan 10, 2004 | ||
| Don't be so sure you can write better assembly than a modern compiler. Anyway, this was about the SCU DSP for which no HLL compiler exist (to the best of my knowledge. To the OP, I would still suggest not bothering with it until you actually have verified you need added performance that can be gained from using the DSP. | ||||
 |
Mask of Destiny | Jan 10, 2004 | ||
| A skilled asm programmer can still beat out a modern optimising compiler. This is particularly true of the SuperH family when using gcc since that comipler is poorly optimized for that chip. | ||||
|
antime | Jan 10, 2004 | ||
| A skilled programmer maybe, but how many people here know the pipelining rules by heart? Even many of the simpler optimizations (CSE etc.) are often missed or even ignored for clarity's sake, not to mention many of the unintuitive and non-obvious transforms compilers perform. | ||||
 |
PyroMeistar | Jan 10, 2004 | ||
Using the DSP was actually a way of complicating the task  DSP assembly seems to be pretty obscure from the sample I've seen in SEGA docs. I will probably use the master SH2 to do the transformations.My project is mostly about pushing the Saturn to it's limit (a challenge a friend of mine threw me). It will be a tribute to Streets of Rage, Puchout style (Yes! SOR in 3D!) Since the game itself will require very little processing power to maintain, I will use the Slave SH2 as "VDP0" and write my own polygon filler to draw triangles. VDP0 will draw animated characters while VDP1 will draw 3D background elements. I plan to run the game in 704 X 480 256 colors/pure flicker mode  .I will write critical loops (75% of the code ) in assembly. (I have some experience in pipelining since my primary development experience comes from Pentium chips with their multiple ALUs.) I have yet to discover the subtleties of the SuperH2... and also the true power of VDP1 since the 200,000 poly/sec stat isn't nearly precise enough...As I'm working alone on this, I will probably not release anything before 4 years... see you in 2008!  BTW. antime, your page was VERY helpful to me! Thanks! | ||||
 |
AntiPasta | Jan 11, 2004 | |||
I could also say, why do you want to use C? Both have their own advantages, and in my opinion, assembly language, even though its not used much on PCs anymore, has more use on closed systems. There as a time PS2 games had to be written in assembly if I recall correctly Personally I (having done 99% of my programming in assembly over the last years) can't really grasp the fear & loathing some programmers seem to hold of assembly language. It even went that far as people calling me stupid and old-fashioned because I advocated the use of assembly. I started doing computer science at the University of Leiden this year, and it amazed me that the majority of my classmates (roughly 30 total) had done some programming, but only 2 others knew assembly. When I did my presentation on ASM, most of them looked very surprised by the whole concept of assembly, let alone why anyone would use it. Good thing we'll all be thought MIPS assembly - my personal favorite - next year, that'll teach 'em I apologize for this rant, now anyone got a doc on SH2 optimization? | |||||
|
Mask of Destiny | Jan 11, 2004 | ||
|
The SH-2 programmer manual from Hitachi does a good job of describing all the pipeline rules. Assembly is great for hardware programming. After programming the Sega CD in assembly, moving to C seemed very limiting. A human would make a very poor C compiler, and I would imagine a modern compiler could easily beat out a human trying to make optimised assembly out of C source; however, the assembly programmer doesn't have to do that. He is not bound by the limitations of the C environment and can do things in such a way that makes the most sense for speed. I can't cite examples on the SH-2 as I've hardly done any programming for the chip, but on the 68K I can simply point to the way argument passing to functions is handled. C almost always not only uses the stack to pass arguments (which is incredibly slow on the 68000 due to its slow memory bus), but it uses it in an inefficient way by using stack frames (which chew up an extra address register and stack space). Besides, the assembly programmer can optimize with knowledge of the data the program will encounter, a compiler cannot. Assembly shouldn't be used for everything, but I still think it is appropriate for embeded computers (and consoles, sometimes), and systems where every ounce of speed is important. | ||||
|
antime | Jan 11, 2004 | ||
|
A compiler is bound by the CPU ABI and calling convention, which is kind of essential if you're going to mix code from different compilers. Not a very good example of optimization, since if you have lots of parameters you'll be passing them through pointers even in assembly. For small, often-called functions you'll want to avoid passing many parameters or saving/restoring registers will start getting expensive. (GCC supports the regparm function attribute, but I don't know if it applies to other platforms than x86.) A HLL programmer can also optimize the programs according to the data, and if you have the ability to do so you can instrument the program to create optimizer feedback. Getting the best speed out of a HLL is not always easy, and requires good knowledge of both the language and compiler. But you should be able to get within a few percent of handcoded assembly in most cases, and the increased coding speed and ease of maintenance is worth the cost. If you need that last drop squeezed out, identify the spot that takes the most remaining time and optimize that. On SH2, routines I would code in assembly would be fixed-point math subroutines (to use XTRCT, inlined operator functions of a C++ class would be pretty neat) and calculations where you can use the MAC instruction, since at least currently GCC can't emit it. SuperH offers less opportunities for hand coding since you have only one CPU flag (the T bit), and in my experience being able to take full advantage of the CPU flags is one of the most important benefits of coding in assembly. | ||||
|
AntiPasta | Jan 12, 2004 | |||
Yeah, they can, but in my experience those HLL programmers that never came into contact with assembly rarely do. C, C++ and especially Visual Basic makes it extremely simple to do inefficient things. For instance, I had a hard time explaining to my fellow students that you should *NOT* use an int-sized array if it only has to store the values 0, 1, and 2 Or how about that whole OOP idea, sure classes are great but a lot of programmers are just too fanatic with them, as it looks all neat and pretty in C++. When one gets to use classes from assembly code (eg DirectX) they look verry messy and pointless (imho). I think that knowing assembly language makes one a better programmer, not only using asm | |||||