That's the preferred way.
Check GCC docs and examples from Linux kernel .S files
that go through gas (not those that go through as86).
32-bit arguments are pushed down stack in reverse syntactic order
(hence accessed/popped in the right order),
above the 32-bit near return address.
%ebp, %esi, %edi, %ebx are callee-saved,
other registers are caller-saved;
%eax is to hold the result,
or %edx:%eax for 64-bit results.
FP stack: I'm not sure,
but I think it's result in st(0), whole stack caller-saved.
Note that GCC has options to modify the calling conventions
by reserving registers, having arguments in registers,
not assuming the FPU, etc. Check the i386 .info pages.
Beware that you must then declare the cdecl or regparm(0)
attribute for a function that will follow standard GCC calling conventions.
See in the GCC info pages the section:
C Extensions::Extended Asm::.
See also how Linux defines its asmlinkage macro...
ELF vs a.out problems
Some C compilers prepend an underscore before every symbol,
while others do not.
Particularly, Linux a.out GCC does such prepending,
while Linux ELF GCC does not.
If you need cope with both behaviors at once,
see how existing packages do.
For instance, get an old Linux source tree,
the Elk, qthreads, or OCaml...
You can also override the implicit C->asm renaming
by inserting statements like
void foo asm("bar") (void);
to be sure that the C function foo
will be called really bar in assembly.
Note that the utility objcopy, from the binutils package,
should allow you to transform your a.out objects into ELF objects,
and perhaps the contrary too, in some cases.
More generally, it will do lots of file format conversions.
Direct Linux syscalls
Often you will be told that using libc is the only way,
and direct system calls are bad.
Believe it, unless of course
you're specifically writing your own replacement for the libc,
adapted to your specific language or memory requirements or whatever.
But you must know that libc is not sacred, and in most cases
libc only does some checks, then calls kernel, and then sets errno.
You can easily do this in your program as well (if you need to),
and your program will be dozen times smaller, and
this will also result in improved performance, just because
you're not using shared libraries (static binaries are faster).
Using or not using libc in assembly programming is more a question of
taste/belief than something practical.
Remember, Linux is aiming to be POSIX compliant, so
does libc. This means that syntax of almost all libc "system calls" exactly
matches syntax of real kernel system calls (and vice versa). Besides, modern
libc becomes slower and slower, and eats more and more memory, and so, cases
of using direct system calls become quite usual.
But.. main drawback of throwing libc away is that possibly you will need to
implement several libc specific functions (that are not just syscall wrappers)
on your own (printf and Co.).. and you are ready for that, aren't you? :)
Here is summary of direct system calls pros and cons.
Pros:
smallest possible size; squeezing the last byte out of the system.
highest possible speed; squeezing cycles out of your favorite benchmark.
no pollution by libc cruft.
no pollution by C calling conventions
(if you're developing your own language or environment).
static binaries make you independent from libc upgrades or crashes,
or from dangling #! path to a interpreter (and are faster).
just for the fun out of it
(don't you get a kick out of assembly programming?)
Cons:
If any other program on your computer uses the libc,
then duplicating the libc code will actually
waste memory, not save it.
Size is much better saved by having some kind
of bytecode, wordcode, or structure interpreter
than by writing everything in assembly.
(the interpreter itself could be written either in C or assembly.)
Services redundantly implemented in many static binaries
are a waste of memory.
But you can put your libc replacement in a shared library.
The best way to keep multiple binaries small is
to not have multiple binaries, but instead
to have an interpreter process files with #! prefix.
This is how OCaml works when used in wordcode mode
(as opposed to optimized native code mode),
and it is compatible with using the libc.
This is also how Tom Christiansen's
Perl PowerTools
reimplementation of unix utilities works.
Finally, one last way to keep things small,
that doesn't depend on an external file with a hardcoded path,
be it library or interpreter,
is to have only one binary,
and have multiply-named hard or soft links to it:
the same binary will provide everything you need in an optimal space,
with no redundancy of subroutines or useless binary headers;
it will dispatch its specific behavior
according to its argv[0];
in case it isn't called with a recognized name,
it might default to a shell,
and be possibly thus also usable as an interpreter!
You cannot benefit from the many functionalities that libc provides
besides mere linux syscalls:
that is, functionality described in section 3 of the manual pages,
as opposed to section 2,
such as malloc, threads, locale, password,
high-level network management, etc.
Consequently, you might have to reimplement large parts of libc,
from printf to malloc and gethostbyname.
It's redundant with the libc effort,
and can be quite boring sometimes.
Note that some people have already reimplemented "light"
replacements for parts of the libc -- check them out!
(Rick Hohensee's
libsys,
Christian Fowelin's
libASM,
asmutils project is working on pure assembly libc)
Static libraries prevent your benefitting from libc upgrades
as well as from libc add-ons such as the zlibc package,
that does on-the-fly transparent decompression
of gzip-compressed files.
The few instructions added by the libc are
a ridiculously small speed overhead as compared
to the cost of a system call.
If speed is a concern, your main problem is in
your usage of system calls, not in their wrapper's implementation.
Using the standard assembly API for system calls is much slower
than using the libc API when running in micro-kernel versions
of Linux such as L4Linux,
that have their own faster calling convention,
and pay high convention-translation overhead
when using the standard one
(L4Linux comes with libc recompiled with their syscall API;
of course, you could recompile your code with their API, too).
See previous discussion for general speed optimization issue.
If syscalls are too slow to you,
you might want to hack the kernel sources (in C)
instead of staying in userland.
If you've pondered the above pros and cons,
and still want to use direct syscalls
(as documented in section 2 of the manual pages),
then here is some advice.
You can easily define your system calling functions
in a portable way in C (as opposed to unportable using assembly),
by including <asm/unistd.h>,
and using provided macros.
Since you're trying to replace it,
go get the sources for the libc, and grok them.
(And if you think you can do better,
then send feedback to the authors!)
As an example of pure assembly code that does everything you want,
examine
Linux Assembly Projects.
Basically, you issue an int 0x80,
with the __NR_syscallname number
(from asm/unistd.h)
in eax, and parameters (up to five) in
ebx, ecx, edx, esi, edi respectively.
Result is returned in eax, with a negative result being an error,
whose opposite is what libc would put in errno.
The user-stack is not touched,
so you needn't have a valid one when doing a syscall.
As for the invocation arguments passed to a process upon startup,
the general principle is that the stack
originally contains the number of arguments argc,
then the list of pointers that constitute *argv,
then a null-terminated sequence of null-terminated
variable=value strings for the environment.
For more details,
do examine
Linux assembly resources,
read the sources of C startup code from your libc
(crt0.S or crt1.S),
or those from the Linux kernel
(exec.c and binfmt_*.c in linux/fs/).
Hardware I/O under Linux
If you want to do direct I/O under Linux,
either it's something very simple that needn't OS arbitration,
and you should see the IO-Port-Programming mini-HOWTO;
or it needs a kernel device driver, and you should try to learn more about
kernel hacking, device driver development, kernel modules, etc,
for which there are other excellent HOWTOs and documents from the LDP.
Particularly, if what you want is Graphics programming,
then do join one of the
GGI
or
XFree86
projects.
Some people have even done better,
writing small and robust XFree86 drivers
in an interpreted domain-specific language,
GAL,
and achieving the efficiency of hand C-written drivers
through partial evaluation (drivers not only not in asm, but not even in C!).
The problem is that the partial evaluator they used
to achieve efficiency is not free software.
Any taker for a replacement?
Anyway, in all these cases, you'll be better when using GCC inline assembly
with the macros from linux/asm/*.h
than writing full assembly source files.
Accessing 16-bit drivers from Linux/i386
Such thing is theoretically possible
(proof: see how
DOSEMU
can selectively grant hardware port access to programs),
and I've heard rumors that someone somewhere did actually do it
(in the PCI driver? Some VESA access stuff? ISA PnP? dunno).
If you have some more precise information on that,
you'll be most welcome.
Anyway, good places to look for more information are the Linux kernel sources,
DOSEMU sources (and other programs in the
DOSEMU repository),
and sources for various low-level programs under Linux...
(perhaps GGI if it supports VESA).
Basically, you must either use 16-bit protected mode or vm86 mode.
The first is simpler to setup, but only works with well-behaved code
that won't do any kind of segment arithmetics
or absolute segment addressing (particularly addressing segment 0),
unless by chance it happens that all segments used can be setup in advance
in the LDT.
The later allows for more "compatibility" with vanilla 16-bit environments,
but requires more complicated handling.
In both cases, before you can jump to 16-bit code,
you must
mmap any absolute address used in the 16-bit code
(such as ROM, video buffers, DMA targets, and memory-mapped I/O)
from /dev/mem to your process' address space,
setup the LDT and/or vm86 mode monitor.
grab proper I/O permissions from the kernel (see the above section)
Again, carefully read the source for the stuff contributed
to the DOSEMU project,
particularly these mini-emulators
for running ELKS and/or simple .COM programs under Linux/i386.
Most DOS extenders come with some interface to DOS services.
Read their docs about that,
but often, they just simulate int 0x21 and such,
so you do "as if" you are in real mode
(I doubt they have more than stubs
and extend things to work with 32-bit operands;
they most likely will just reflect the interrupt
into the real-mode or vm86 handler).
DJGPP comes with its own (limited) glibc derivative/subset/replacement, too.
It is possible to cross-compile from Linux to DOS,
see the devel/msdos/ directory of your local FTP mirror for metalab.unc.edu
Also see the MOSS dos-extender from the
Flux project
from university of Utah.
Other documents and FAQs are more DOS-centered.
We do not recommend DOS development.
This HOWTO is not about Windows programming,
you can find lots of documents about it everywhere..
The thing you should know is that
Cygnus Solutions
developed the cygwin32.dll library, for GNU programs to run on Win32 platform.
Thus, you can use GCC, GAS, all the GNU tools, and many other Unix applications.
Take a look on their webpage.
Control is what attracts many OS developers to assembly,
often is what leads to or stems from assembly hacking.
Note that any system that allows self-development
could be qualified an "OS",
though it can run "on the top" of an underlying system
(much like Linux over Mach or OpenGenera over Unix).
Hence, for easier debugging purpose,
you might like to develop your "OS" first as a process running
on top of Linux (despite the slowness), then use the
Flux OS kit
(which grants use of Linux and BSD drivers in your own OS)
to make it standalone.
When your OS is stable, it is time to write your own
hardware drivers if you really love that.
This HOWTO will not cover topics such as
Boot loader code & getting into 32-bit mode,
Handling Interrupts,
The basics about Intel protected mode or V86/R86 braindeadness,
defining your object format and calling conventions.
The main place where to find reliable information about that all,
is source code of existing OSes and bootloaders.
Lots of pointers are on the following webpage:
http://www.tunes.org/Review/OSes.html
