whose 8051 cc omits the insignificant bytes of call instructions

Subject: whose 8051 cc overlays static inline stack frames

And is there any persuading 8051 cc folk to work to eliminate the waste of the call instruction?

People I know in real life are actually shipping a chipset whose effective cost pointlessly includes an external memory merely because their C compiler doesn't know how to eliminate the call instruction. They consequently blew out of masked rom space within their die.

That is, they ship code that doesn't fit:

_asm { call a; call b; call c; ... }

Even though they have the time for code that does fit to work:

{ a, b, c ... }

And indeed they have time for the more extremely smaller alternative to work:

{ '\0', '\1', '\2', ... }

What they don't have people/ time for is the translation by hand. And they're too invested in vendor-specific extensions to contemplate switching compiler vendors. But again, so far as I know, offline, there's no convincing the compiler vendor that this is a problem worth solving, so I'm here now, hi.

Maybe someone somewhere sells a translator from 8051 machine code back to 8051 machine code that disassembles and reassembles the code image in order to omit the insignificant bytes of the call instructions? We could feed in a symbol table to let us declare which code we don't want compressed.

Thanks in advance, Pat LaVarre

formatting link
formatting link

Reply to
PPAATT
Loading thread data ...

Ah, so maybe there's still a place for 100% assembler. It's simple, consistent, reusable, compact, efficient, fast, doesn't bite yer bum and as long as you don't want to port it to a different *type* of micro there's no substitute (and no I don't want/need printf or floating point libs either).

Ian

Reply to
Ian Bell

That's not code at all. It's just a table of some things.

If those guys you're talking about don't know how to code a loop over an array of function pointers when they need one, there's not much a compiler can do to help them with their job.

What you're asking about here is a good deal more than just an optimizing compiler. You're effectively asking for the mythical "do what I mean" machine, which we all know doesn't exist.

IMHO, the compiler maker was completely right on this one. Turning a sequence of calls into a loop over an address table *may* be a useful plan at times. OTOH, how often do you really happen to have a table of that kind, all function neither taking argument nor returning anything, that this optimization would actually save anything?

It's feature that would be nice to have if it existed, but that doesn't make the fact it apparently doesn't a "problem worth solving."

But anyway: why do you ask us? I think you really should download yourself an evaluation copy of the market leader(s) in 51 C compiler technology and see for yourself what it does, and what it doesn't do. You just *might* be surprised...

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

So far as I know I was actually using the market leader. That's the compiler that disappointed me, as described.

The comparison I ran began in the 80's with some proprietary C code, which I first saw in 1994. In 1995 someone translated that C code to

8051 asm, in order to save much money by substituting the 8051 for a 16-bit micro. In 2001 or so I tried translating back to C, as we swapped out some front-end hardware. The effort wasn't wasted: I've since run the C code as a virtual device on other platforms. But neither could I make the argument to substitute C for asm on the 8051. The C compiler I tried wasn't up to the job, in the ways I have described and so on.

Not at all. I'm asking for the C compiler to give me a way to say what I mean: I'm asking how can I produce reasonable 8051 machine code. The machine code I'm getting isn't reasonable, "in the ways I have described and so on".

The inline keyword of C99 is an advance. That lets me say that when I mean that, without demanding that the compiler always spend time looking to see if I called a static subroutine only once.

Is there no comparable advance for saying I'd like to use a more space-efficient calling convention than normal?

Is there no comparable advance for saying I'd like to use a more space-efficient local variable allocator than normal?

Offline I didn't find any compiler folk who even understood C compilers today leave a raft of problems unsolved.

Indeed I don't see C compiler folk actively encouraging people to review their work. To really appreciate what the mis/translation said, I resorted to writing my own disassembler and flow analysis, so that I could look at all of the 64 KiB image at once. Nothing like bothering to look at data for discovering what's wrong with it.

Pat LaVarre

Reply to
Pat LaVarre

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.