But it is cygwin related.

[Enrique Perez-Terron]

On Thu, 04 Apr 2013 17:46:12 +0200, Frank Farance <frank@farance.com>  
wrote:
[snip]
> Now, for whatever reason, a different set of calculations are needed and  
> assembler is the best software engineering solution (for whatever  
> reason).  As a programmer, I can think of several ways that will cause a  
> visual image to appear on the screen with the result, but some of them  
> will not be compatible with B with the pipeline:
>
> # Note: B has similar functionality as the "wc" program
> $ A | B
[snip]

Frank,
Believe me, there is not much cygwin-ish about this. The easiest way to  
achieve what you describe above, is to write a function in assembly, that  
is called from a C program implementing your A component.

That way you leave it to the gcc toolchain to interface to the I/O  
routines in the standard library, while you can program the actual  
computation in assembly. As others have pointed out, the standard library  
is not quite the drag that you may have thought.

Also, I do not think that there are any clever ways that interface with  
output routines in the cygwin dll any better than the compiler does. You  
could try to browse the source code of these routines with an eye to  
copying some of it into your assembly program, but you will likely find  
that it constitutes a kind of maze that is quite hard to understand, and  
that very few people on this planet understand well. Avoiding this dll  
means intefacing directly with whatever Microsoft offers. Ultimately there  
almost certainly are some kind of "interrupt" assembly instructions that  
the Windows libraries execute, that actually triger the transition to  
Windows kernel space, but again, that is really esoteric stuff that almost  
nobody knows, and that maybe changes between versions of the OS in quite  
hopelessly complicated and unpredictable ways.

To help you get started, I shall hint you, but please bear with me if I  
make some mistake because I have not done this for quite many years.

You will have to google "calling convention" and ask around about the  
specifics of interfacing assembly functions and C code. Such interfacing  
is specific for each compiler, even if there are some standardization  
efforts too -- google "ABI", "cdecl", "stdcall". The ABIs are specific for  
the architecture, and watch out for any differences between x86 and amd64.

The answers are not different for the Cygwin environment as compared to  
Linux or Windows.

Using the gcc toolchain there are some possible simplifications if you can  
write inline assembly in the C function. That way you leave to the  
compiler to arrange the correct calling sequence, but instead you need to  
figure out how to tell the gcc compiler how to place the named arguments  
in specific registers after the function entry. You can even let the tools  
choose the registers, you just refer to them as %0, %1, etc. I remember I  
saw many examples of this in the linux kernel code - I think it was in the  
start-up code or in the syscall interface code. I recommend reading  
http://www.ibm.com/developerworks/library/l-ia/index.html.

Just a small detail: In the assembly files, add an underscore in front of  
the function name label. Omit this underscore in the function call in the  
C code. (Google "name mangling".) -- and remember to declare: extern  
mytype_t myfunction(arg_one_type_t, arg_two_type_t);

Notice that the gnu assembly is somewhat different from the intel assembly  
code.

You may combine writing pure assembly files with inline assembly in the C  
function. To do that you call your assembly code (or even jump to it) from  
the inline assembly in the C function. That way you may implement your own  
calling convention.

Thanks, and good luck.
-Enrique

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple