[A89] Re: Quiet in here... let's discuss something!


[Prev][Next][Index][Thread]

[A89] Re: Quiet in here... let's discuss something!




Hi!

| And it's hard to optimize the S (ASM) files,
| since its not human typed, labels are called L1 L2 L3 etc.

That sounds logical.  Well, I implemented a '-g' switch in tigcc.exe, which
inserts the C code into the .s file as comments.  It doesn't work completely
when optimizing, of course, but I wonder if it could be of any help.

| C compiled code
| is differs from code in ASM. In ASM paramaters are passed trough
registers,
| in this routine i see the stack is used.

That is true, although the latest version of TIGCC supports explicit
register specification.  We could make use of that (both when compiling the
code to assembly, and when calling the function).  In fact, this could be
done for all TIGCC functions, just nobody did it yet.

| I compile with a68k, not with GNU, the code is a bit different.

I know, but I think it should be easy to switch.

| I like ASM because it can be perfectly optimized.

Yep.

| A C programmer who doesnt know ASM and a C compiler don't know
| that 30*y is not optimized when it's compiled to mulu #30,y (see my prev
| post).

Yes, but C can be easier to write in.

| I don't think optimizing a compiled C routine is good, rewriting is
| better.

Probably.

| But there are already some ASM sprite routines, aren't they? Or
| can't they be used in TIGCC

Technically, they can.  The thing is that a lot of people once asked Zeljko
to include standard sprite routines in TIGCC, which would provide basic
functionalities for general cases.  Of course, really serious programmers
always use sprite functions which fit exactly to their needs, but the idea
behind this was that there are some standard functions in TIGCC that remove
the need for an external library of them.  Now you gave me the idea that
they could be optimized in assembly.

Sebastian





References: