This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: But it is cygwin related.

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

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

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.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]