On Thu, 04 Apr 2013 17:46:12 +0200, Frank Farance <fr...@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
