Re: gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

On Aug 4, 2014, at 6:00 AM, Gerald Pfeifer wrote: > On Wed, 23 Jul 2014, Hans-Peter Nilsson wrote: >> The page is >> unfortunately out of date (e.g. binutils+sim now lives in the >> same git repo) but it gives you the idea. > > Sooo, any volunteer to up

gcc.gnu.org/simtest-howto.html (was: Question for ARM person re asm_fprintf)(

On Wed, 23 Jul 2014, Hans-Peter Nilsson wrote: > The page is > unfortunately out of date (e.g. binutils+sim now lives in the > same git repo) but it gives you the idea. Sooo, any volunteer to update this page? Doesn't have to be perfect, even incremental i

Re: Question for ARM person re asm_fprintf

Not that the following would constitute the actual testing usually required for a patch, but: /path/to/toplevel/configure --target=arm-eabi && make all-gcc # Yay, the compiler-proper for a "bare iron" ARM compiler. ./gcc/xgcc -B./gcc -S test.c Woot, compiled your first ARM program. :) Just e

Re: Question for ARM person re asm_fprintf

On Mon, 21 Jul 2014, David Wohlferd wrote: > I have been looking at asm_fprintf in final.c, and I think there's a design > flaw. But since the change affects ARM and since I have no access to an ARM > system, I need a second opinion. There's this thing called cross-compila

Re: Question for ARM person re asm_fprintf

Hi David, On 22/07/14 02:46, David Wohlferd wrote: I have been looking at asm_fprintf in final.c, and I think there's a design flaw. But since the change affects ARM and since I have no access to an ARM system, I need a second opinion. asm_fprintf allows platforms to add support fo

Question for ARM person re asm_fprintf

I have been looking at asm_fprintf in final.c, and I think there's a design flaw. But since the change affects ARM and since I have no access to an ARM system, I need a second opinion. asm_fprintf allows platforms to add support for new format specifiers by using the ASM_FPRINTF_EXTEN

Re: asm_fprintf inefficiency?

On 11/05/2010 08:10 AM, Jay K wrote: the checking for puts_locked... the fact that asm_fprintf calls putc one character at a time, which probably benefits from _unlocked. Honest question: is asm_fprintf in the profile at all, even at -O0? Paolo

Re: asm_fprintf

Jay K writes: > > And putc_unlocked is a macro which appends to a buffer. puts is not. > > > I *assumed* there is puts_unlocked like all the other *_unlocked. > Maybe not. There is an fputs_unlocked. But it's still a function, not a simple macro. > > (Really I'd rather gcc just output .

RE: asm_fprintf

> And putc_unlocked is a macro which appends to a buffer. puts is not. I *assumed* there is puts_unlocked like all the other *_unlocked. Maybe not. > (Really I'd rather gcc just output .o files directly...) > It would be an interesting project, but it's not a major component of > opti

Re: asm_fprintf inefficiency?

Jay K writes: > 1) asm_fprintf probably should skip from % to %, calling > puts on each span, instead of putc one at a time. > Granted, its input strings tend to be short. And putc_unlocked is a macro which appends to a buffer. puts is not. It's not clear that your proposal would

asm_fprintf inefficiency?

so..I was bemaining to self extra #ifs, extra autoconf.. the checking for puts_locked... the fact that asm_fprintf calls putc one character at a time, which probably benefits from _unlocked. 1) asm_fprintf probably should skip from % to %, calling puts on each span, instead of putc one at a