New 'as' port

[Simon Richter]

Hello,

John Moran wrote:

> First, the processor already has an inline assembler, that'll assemble 
> raw/post-processed opcodes. Before I start digging around in the 
> sources, can anyone tell me if there are any other ports that also do 
> this? Or am I on my own? Ideally, I'd like to bypass as much low-level 
> stuff as possible and just send a string from gas to the inline 
> assembler, getting back an opcode.

I don't think this will save you any work. The assembler output is not 
only a "blob" of opcodes but also needs relocation and possibly 
relaxation info. To generate that, you will already need full knowledge 
of the opcodes available to you.

> Second, the existing assembler is supplied as part of a proprietary 
> shared library, with a few external entries (set the current ISA, 
> assemble, return the instruction size, and so on). Can anyone tell me 
> what implications this has for the licence of the completed port? Does 
> the GPL require that any parts of the existing library should also be 
> GPL'ed, or is it only the new code that I write for the port that is 
> affected?

The GPL specifies, among other things, that anyone receiving a binary is 
entitled to also receive a copy of all sources that were used to 
generate that binary, and that the license of any work linked to a GPLed 
work may not interfere with that. So if you ever handed out a binary 
that links to this library, the only way to fulfill the requirements of 
the GPL is to offer complete source for the library to anyone who has 
received that binary.

To sum it up, it is probably best both from a technical and a legal 
standpoint to do it all from scratch.

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20051107/18e19c23/attachment.sig>