other apps that assemble code

other apps that assemble code

[Doug Evans]

Can anyone think of any useful applications that want to
assemble code besides an assembler?

A debugging session?
[I can see perhaps only a minor usefulness here, but maybe there are
cases where it's really useful, and maybe there are other examples.]

Re: other apps that assemble code

[Joel Sherrill]

On Thu, 5 Feb 1998, Doug Evans wrote:

> Can anyone think of any useful applications that want to
> assemble code besides an assembler?
> 
> A debugging session?
> [I can see perhaps only a minor usefulness here, but maybe there are
> cases where it's really useful, and maybe there are other examples.]

Many ROM monitors include an assembler.  I assume it is so code can be
patched in memory and very simple programs can be given directly to the
monitor.

Also people do write assembly language so not all input is compiler
generated. I know this almost qualifies as a smart mouthed suggestion. :)

--joel

Re: other apps that assemble code

[Doug Evans]

   Date: Thu, 5 Feb 1998 11:26:18 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   Also people do write assembly language so not all input is compiler
   generated. I know this almost qualifies as a smart mouthed suggestion. :)

When they do this, is the code ever fed through anything other than
an assembler that takes in assembly files and spits out object files?

The reason I'm asking is that I have an assembly language parser
for some chips and am wondering whether it has any use outside of GAS.

Re: other apps that assemble code

[Richard Earnshaw]

> Can anyone think of any useful applications that want to
> assemble code besides an assembler?
> 
> A debugging session?
> [I can see perhaps only a minor usefulness here, but maybe there are
> cases where it's really useful, and maybe there are other examples.]

How about a compiler.  It doesn't have to spit out assembly language 
directly, and might be able to do a better job in some cases if it could 
write an object file directly.  (or am I missing your point?)

Re: other apps that assemble code

[Joel Sherrill]

On Thu, 5 Feb 1998, Doug Evans wrote:

>    Date: Thu, 5 Feb 1998 11:26:18 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    Also people do write assembly language so not all input is compiler
>    generated. I know this almost qualifies as a smart mouthed suggestion. :)
> 
> When they do this, is the code ever fed through anything other than
> an assembler that takes in assembly files and spits out object files?
> 
> The reason I'm asking is that I have an assembly language parser
> for some chips and am wondering whether it has any use outside of GAS.

I have seen articles about "optimizing assemblers" for really smart cpus
which insert nops, reorder instructions to avoid stalls, reassign
registers, etc.   This type of tools would benefit from a generic assembly
language parser.

Another possible use is an assembly translator which takes code for one
cpu and attempts to convert it to another assembly language.  I know this
sounds scary but on some of the early RTEMS ports (RTEMS was ~20% assembly
then), I used some sed and awk scripts to convert Motorola assembly to
Intel i386 and i960 assembly as a starting point.  A smart tool could save
you a lot of bloody fingers here.

I suspect that Hunter Ready Systems (remember the original VRTX) had an
inhouse product like this since they claimed the entire kernel was in
assembly.  I never could figure out how that would be practical to maintin
unless it was written in a "pseudo-assembly" and converted.

Just some ideas.

--joel

Re: other apps that assemble code

[Doug Evans]

   Date: Thu, 05 Feb 1998 17:41:27 +0000
   From: Richard Earnshaw <rearnsha@arm.com>

   > Can anyone think of any useful applications that want to
   > assemble code besides an assembler?
   > 
   > A debugging session?
   > [I can see perhaps only a minor usefulness here, but maybe there are
   > cases where it's really useful, and maybe there are other examples.]

   How about a compiler.  It doesn't have to spit out assembly language 
   directly, and might be able to do a better job in some cases if it could 
   write an object file directly.

Yes, but in this case does the compiler internally create assembly code
and then parse that assembly code to spit out the object file?
Maybe there is a compiler that does so, but I would think it would just
keep the insns internally in some form and not deal with assembly code at all.

   (or am I missing your point?)

I'm not sure but I think so.

Re: other apps that assemble code

[Doug Evans]

   Date: Thu, 5 Feb 1998 11:47:36 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   I have seen articles about "optimizing assemblers" for really smart cpus
   which insert nops, reorder instructions to avoid stalls, reassign
   registers, etc.   This type of tools would benefit from a generic assembly
   language parser.

Ok, but methinks this is still just GAS.
Or am I misunderstanding something?

   [...]

   Just some ideas.

Thanks [and rearnsha too].
Keep 'em coming ...

Re: other apps that assemble code

[Nick Clifton]

: Date: Thu, 5 Feb 1998 09:48:44 -0800
: From: Doug Evans <devans@cygnus.com>
: 
:    Date: Thu, 05 Feb 1998 17:41:27 +0000
:    From: Richard Earnshaw <rearnsha@arm.com>
: 
:    > Can anyone think of any useful applications that want to
:    > assemble code besides an assembler?
: 
:    How about a compiler.  It doesn't have to spit out assembly language 
:    directly, and might be able to do a better job in some cases if it could 
:    write an object file directly.
: 
: Yes, but in this case does the compiler internally create assembly code
: and then parse that assembly code to spit out the object file?
: Maybe there is a compiler that does so, but I would think it would just
: keep the insns internally in some form and not deal with assembly code at all.

Well one compiler I worked on did this, but it did have to include a
disassembler so that it could support the -S option.

:    (or am I missing your point?)
: 
: I'm not sure but I think so.

Nick

Re: other apps that assemble code

[Robert Lipe]

>    I have seen articles about "optimizing assemblers" for really smart cpus
>    which insert nops, reorder instructions to avoid stalls, reassign
>    registers, etc.   This type of tools would benefit from a generic assembly
> 
> Ok, but methinks this is still just GAS.
> Or am I misunderstanding something?

I'm not sure if it really goes to answer the original question or not,
but there exist highly optimizing assemblers.  The one I worked with was
the MIPS assembler.  I don't know if that technology was kept when MIPS
collapsed into SGI or not.  By that time, I'd defected from that train.

The mips uopt pass did many of the same optimizations at the assembler
level that GCC does a couple of levels up.  It did flow analysis,
constant propogation, branch prediction and all sort os wild and crazy
things.  The "optimization" in GAS is far less ambitious.

This is the lone thing that I actually miss about the MIPS tools.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

Re: other apps that assemble code

[Joel Sherrill]

On Thu, 5 Feb 1998, Doug Evans wrote:

>    Date: Thu, 5 Feb 1998 11:47:36 -0600 (CST)
>    From: Joel Sherrill <joel@OARcorp.com>
> 
>    I have seen articles about "optimizing assemblers" for really smart cpus
>    which insert nops, reorder instructions to avoid stalls, reassign
>    registers, etc.   This type of tools would benefit from a generic assembly
>    language parser.
> 
> Ok, but methinks this is still just GAS.
> Or am I misunderstanding something?

I guess it could be but would it be cleaner to have it as a separate tool
which manipulated source.  Technically either approach is viable.

From an implementation standpoint, having a separate tool might make that
tool easier to update/port.  From a strict viewpoint, gas shoud only take
assembler and generate object.  That is a difficult enough process as it
is.  Having to deal with possible code reordering, nops could only make
gas more complex and difficult to maintain.

I don't know much about gas internals.  Does it have an internal
representation which could be manipulated like this?

-joel

Re: other apps that assemble code

[Doug Evans]

   Date: Thu, 5 Feb 1998 12:49:11 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   >    Date: Thu, 5 Feb 1998 11:47:36 -0600 (CST)
   >    From: Joel Sherrill <joel@OARcorp.com>
   > 
   >    I have seen articles about "optimizing assemblers" for really smart cpus
   >    which insert nops, reorder instructions to avoid stalls, reassign
   >    registers, etc.   This type of tools would benefit from a generic assembly
   >    language parser.
   > 
   > Ok, but methinks this is still just GAS.
   > Or am I misunderstanding something?

   I guess it could be but would it be cleaner to have it as a separate tool
   which manipulated source.  Technically either approach is viable.

   >From an implementation standpoint, having a separate tool might make that
   tool easier to update/port.  From a strict viewpoint, gas shoud only take
   assembler and generate object.  That is a difficult enough process as it
   is.  Having to deal with possible code reordering, nops could only make
   gas more complex and difficult to maintain.

   I don't know much about gas internals.  Does it have an internal
   representation which could be manipulated like this?

Nope (or rather, yep for some particular ports for some limited forms of
optimization).

Re: other apps that assemble code

[Richard Stallman]

    The mips uopt pass did many of the same optimizations at the assembler
    level that GCC does a couple of levels up.  It did flow analysis,
    constant propogation, branch prediction and all sort os wild and crazy
    things.  The "optimization" in GAS is far less ambitious.

I made a basic design decision long ago not to try to do anything like
this.  The reason is that it involves pushing most of the compiler and
linker down into the assembler.  That contorts the design and makes a
lot of extra work, and it just isn't worth that much trouble.