Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#592 printf_fast.c hangs with --i-code-in-asm

closed-fixed
Erik Petrich
None
3
2013-05-25
2003-09-23
Erik Petrich
No

sdcc -c --i-code-in-asm printf_fast.c

hangs in printIline() in asm.c at the statement

icTab->iCodePrint(pipeStream, ic, icTab->printName);

It seems to be a pipe related problem, since I can
replace this with

icTab->iCodePrint(stdout, ic, icTab->printName);

and it no longer hangs. Someone who is a C I/O guru,
please look into this. (My development computer is
running Linux 2.4.20-20.9)

Discussion

  • Logged In: NO

    Linux has a fixed pipe size of 4kB. If you try to write more
    than that, the routine will wait until something got read.
    But this is only possible if you use different taks for
    reading and writing to the pipe.
    A solution would be to make sure, that no more than 4kB get
    written to the pipe.

    regards
    Klaus Flittner

     
  • Erik Petrich
    Erik Petrich
    2003-09-26

    Logged In: YES
    user_id=635249

    Fixed in src/asm.c 1.28.

    We don't need to see the inline assembly associated with an
    INLINE iCode twice in the assembly file, so it is now
    omitted from the debugging iCode comments and left to the
    code generator to output as actual code. Thus the pipe
    limitation is avoided.

     
  • Erik Petrich
    Erik Petrich
    2003-09-26

    • milestone: --> fixed
    • assigned_to: nobody --> epetrich
    • status: open --> closed-fixed
     
  • Borut Ražem
    Borut Ražem
    2003-10-05

    Logged In: YES
    user_id=568035

    I rewrote printIline() to use a temporary file instead a pipe.
    So Erik, you may reconsider to revert your fix: the limitation
    of 4k (on Windows was even worse: 265 bytes ;-) has been
    removed. But anyway, only the first inline asm line was
    written by printIline(), so I think the Erik's fix can remain.

    I'm still not totally satisfied with the solution. Using a memory
    buffer instead temporary files or pipes would be much better
    solution, but it takes more work. Maybe in the next iteration...

    Borut