Howdy;

I'm currently running a 32-bit amd sempron, which with a
little luck, I'll be upgrading to 64-bits soon, In any
case, does anyone have some sample assembler code that
shows how to read from/write to pipes? Both 32 and 64
bit asm source would be appreciated.

Thanks.

Bill

gcc -S my_pipe_demo.c

Basically, you use linux SVC's both in C and Assembly, so the main difference is that Assembly-code is harder to write, but you cannot use it if you change platform.

SVC? Whats that?

Bill

a hello world example that comes with FASM, for amd64
32bit pipe example below
it demonstrates write() and exit() system calls

man 2 pipe tells you the argument pipe() takes is room for two file descriptors
a full example for 32bit linux:
as man 2 pipe says, you write to the second fd and that gets sent to the first fd (other way around does not work)


if something is not clear, ask
i'd advise to read the fasm manual first until you fully understand the hello world example
then to read the pipe() man page

edit: sorry, that you don't have a 64bit cpu went over my head
i'l make a 32bit example, just a sec
edit2: made it, hf

1 members found this post helpful.

SVC means 'Supervisor Call'; also known as 'system call' or 'syscall'. Meaning: the user program asks the kernel (or with another word: the executive) to do something.

updated post above with a 32bit example


syscall or system call, the kernel isn't a supervisor (in this case, at least)

Off: The same thing might go under different names: supervisor, executive, kernel...)

That question tells me you know little if any x86 assembler.

The code you asked for is a bad idea, but still quite easy. So if you knew a little bit about x86 assembler, you would not have needed to ask. But if you don't know even a little about x86 assembler then you probably don't know that what you are asking for is a pointless sidetrack from learning any.

Do you know any C or C++ ?

If yes to either, then the best place to start learning assembler is learning to write C-callabe functions in assembler (not whole programs) that do computations (not I/O).

That is not just the right point of view for learning assembler. It is the right point of view for any real use of asembler.

Learning the basic framework for asm code to be a Linux program is cute bit of esoteric info. But is a waste of effort for fundamentally useless info. Write the framework of a program in some language that allows calling functions via a C interface then write your asm code as functions called by that interface.

Learning how to do Linux I/O directly from asm is similarly a waste of effort. It isn't useful in itself and it doesn't help you with anything else. If your asm code needs to do I/O have it call a C function that does the I/O.

But learning how to call C-callable functions from asm and learning how to write a C-callable function in asm has real value. First it is the kind of thing you would do in asm if you had a real reason to use asm. But maybe more importantly, it will give you some real extra insight into the important "under the hood" functioning of every program you write in other languages. It will make you better at designing and debugging high level language programs.

That is a slightly flawed suggestion in the context of the original question, but a very very important suggestion if the OP instead starts to learn asm the right way.

Some of the rules of function calling especially parameter passing in x86-64 are a bit strange and are documented at a highly precise and abstract level, which makes them nearly impossible to understand if you don't already know the basic ideas. Learning by example is much better than from formal rules anyway.

Write a C function that calls another C function passing some parameters. Compile it with gcc -S and look at how to sets up the parameters and makes the call. Write the function it calls and have it do something trivial with the parameters. Look at the generated asm for that and see how a C-callable function is organized and how it gets its parameters etc.

Later read the official rules (for 32-bit you can easily infer the rules from a few examples. But for 64-bit you won't infer the rules from examples nor understand the rules without examples. You need both).

Thank you very much, Sir. Definitely the most helpful reply by far. I can allready see a couple errors I've been making.

Bill

Ah, the last two I'm most familiar with. 'Supervisor Call', I
don't see near as much. When it comes to abreviations and acronyms, I try to limit myself to those I find the most useful,
as some idiot is allways coming up with new ones by the bushel basket full, trying to sound cool for the boss or whatever.

Bill

Also: nearly all the time, you do not want to write assembly-code directly ... except maybe within short asm { } blocks within a C/C++ program. You will not generate better object-code than an optimizing compiler would have done.

i beg to differ