Quote:>> I think you're much better off not doing it this way
>> - there's no clearly defined semantic for asm.
>> Why not just use a separate .s file ?
>> If you want this assembly sequence to be inlined,
>> the only bet in Sun compiler is to use inline template (.il)
>> which has a clearly defined interface semantic.
> Does anybody remember ASM-One on Amiga? Great macro assembler with a rich
> IDE and a phenomenal de*, capable of generating executables straight
> from assembler source. Is there such a thing for UNIX platforms???
Looks to me like the assembler can no longer generate executable code
directly (I think maybe sometime back in ancient history they could if
there were no unresolve symbols. The simplest I can get for true.s
(static (unsupported) implementation of true(1)) that looks like:
==================== cut here =================
#include <sys/syscall.h>
#include <sys/trap.h>
/* following from unistd.h, which is not suitable for include by "as" */
#define EXIT_FAILURE 1
#define EXIT_SUCCESS 0
.section ".text"
.global _start
.align 4
_start:
mov SYS_exit,%o0
mov EXIT_SUCCESS, %g1
ta ST_SYSCALL
==================== cut here =================
is to use the commands:
$ as -P -D_ASM true.s
$ ld -o true true.o
Since I wanted to use some cpp symbolic constants, the -P option is to
cause "as" to preprocess with cpp; the -D_ASM is to suppress C code in
sys/syscall.h, leaving just #defines. Note: most C include files are
_not_ suitable for including in assembler programs - these two are
exceptions, probably because the library stubs that have to be written in
assembler (well, almost - using syscall(3ucb) is mostly hokey, and at
least it would still need ST_SYSCALL from sys/trap.h 'cause syscall()
itself has to be written in assembler) need them. After the "as" command,
the "ld" command (linker) is needed to convert the relocatable (even
though fully resolved) object into an executable.
Actually, like that, it's functionally static (using my code for the
system call rather than the library wrapper) but still technically dynamic
(even though not linked with anything). If one wanted it truly static,
one would need the -dn option on the ld command. The smallest I can seem
to get "true" down to is with
ld -dn -s -o true true.o
followed by
mcs -d true
but even that is a bit larger than it used to be because even though mcs
got rid of the .comment section, for some stupid reason it still left
".comment" in the .shstrtab section. So I'm only down to 320 bytes instead
of 312 like I used to be able to get down to (both SPARC). Darn if I know
why that happened (or what to do about it, or without a lot more research
what the absolute minimum ELF executable would look like - this is as far
as I wanted to go just out of mild curiosity). (Anyway, the
result is a bit faster than /bin/true, not that it matters, because in
a decent shell like ksh instead of sh, "true" is a builtin.)
If you want to debug the executable, do _not_ use the -s option of "ld",
since it strips symbols.
As an alternative to -P for cpp on the "as" command, you might consider
using -m to run m4, which is probably more sensible for most assembler
than cpp anyway (there being so few existing C include files suitable
for use with assembler).
Your de* is "adb" - command driven, and none too friendly. On
Solaris 8 and later, there's also "mdb" (and on Solaris 9 and later,
"adb" is emulated by "mdb"). "mdb" is still command driven, but a bit
less cryptic and a lot more powerful.
If you want a GUI, wrap up the "as", "ld", and "mdb" commands in a
Tcl/Tk (or dtksh) script. But the result still isn't going to be
click monkey meets assembler, so why bother? For that matter, I doubt
if enough people write any assembler at all anymore to recoup the cost
of developing a real assembler IDE.
--
by