Portable Assembly

Someone in another group is thinking of using a portable assembler to write 
code for an app that would be ported to a number of different embedded 
processors including custom processors in FPGAs.  I'm wondering how useful 
this will be in writing code that will require few changes across CPU ISAs 
and manufacturers.

I am aware that there are many aspects of porting between CPUs that is 
assembly language independent, like writing to Flash memory.  I'm more 
interested in the issues involved in trying to use a universal assembler to 
write portable code in general.  I'm wondering if it restricts the 
instructions you can use or if it works more like a compiler where a single 
instruction translates to multiple target instructions when there is no one 
instruction suitable.

Or do I misunderstand how a portable assembler works?  Does it require a 
specific assembly language source format for each target just like using the 
standard assembler for the target?

-- 

Rick C

On 2017-05-27, rickman <gnuarm@gmail.com> wrote:

> Someone in another group is thinking of using a portable assembler

You'll have to ask them what they mean by "portable assembler".

The only "portable assemblers" I've ever seen were frameworks that let
you build multiple CPU-specific assemblers from a single source tree.

I vaguely remember one product many years ago that used some sort of
configuration file to define the mnemonics and instruction format for
each architecture.  The base "executable" for the assembler itself was
universal.

But that was simply an implementaiton detail.  You still had to write 
seperate source code for each CPU using that CPU's instruction set.
When you were using it, it wasn't any different than using a set of
seperate assemblers that shared a common macro/directive processor. 

> to write code for an app that would be ported to a number of
> different embedded processors including custom processors in FPGAs.
> I'm wondering how useful this will be in writing code that will
> require few changes across CPU ISAs and manufacturers.
>
> I am aware that there are many aspects of porting between CPUs that
> is assembly language independent, like writing to Flash memory.  I'm
> more interested in the issues involved in trying to use a universal
> assembler to write portable code in general.

You'll have to provide a reference to such a "universal assembler if
you want any real answers.

> I'm wondering if it restricts the instructions you can use or if it
> works more like a compiler where a single instruction translates to
> multiple target instructions when there is no one instruction
> suitable.

AFAIK, you still have to write seperate source code for each CPU
instruction set.

> Or do I misunderstand how a portable assembler works?  Does it
> require a specific assembly language source format for each target
> just like using the standard assembler for the target?

That's all I've ever run across in 35 years of low-level embedded
work...

-- 
Grant

rickman wrote:
> Someone in another group is thinking of using a portable assembler
> to write code for an app that would be ported to a number of
> different embedded processors including custom processors in FPGAs.
> I'm wondering how useful this will be in writing code that will
> require few changes across CPU ISAs and manufacturers.
>
> I am aware that there are many aspects of porting between CPUs that
> is assembly language independent, like writing to Flash memory.  I'm
> more interested in the issues involved in trying to use a universal
> assembler to write portable code in general.  I'm wondering if it
> restricts the instructions you can use or if it works more like a
> compiler where a single instruction translates to multiple target
> instructions when there is no one instruction suitable.
>
> Or do I misunderstand how a portable assembler works?  Does it
> require a specific assembly language source format for each target
> just like using the standard assembler for the target?
>

That's what C is for.

This being said, I've been doing this for
37 years and have only a few times seen an actual need for
portability - usually, the new hardware is so radically
different that porting makes little sense.

-- 
Les Cargill

On 27.5.2017 г. 22:39, rickman wrote:
> Someone in another group is thinking of using a portable assembler to
> write code for an app that would be ported to a number of different
> embedded processors including custom processors in FPGAs.  I'm wondering
> how useful this will be in writing code that will require few changes
> across CPU ISAs and manufacturers.
>
> I am aware that there are many aspects of porting between CPUs that is
> assembly language independent, like writing to Flash memory.  I'm more
> interested in the issues involved in trying to use a universal assembler
> to write portable code in general.  I'm wondering if it restricts the
> instructions you can use or if it works more like a compiler where a
> single instruction translates to multiple target instructions when there
> is no one instruction suitable.
>
> Or do I misunderstand how a portable assembler works?  Does it require a
> specific assembly language source format for each target just like using
> the standard assembler for the target?
>

The only thing of that kind I know of is vpa (virtual processor
assembler) which I have created some 17 years ago.
Takes 68k source and assembles it into power architecture code.
It is a pretty huge thing, all dps (the OS I had originally written
for 68k (CPU32), toolchains, application code for our products etc.
etc. (millions of lines) go through it - and it can do a lot more
than just assemble statements, it does everything I ever wanted
it to do - and when it could not I extended it so it could.

It would be a lot simpler for a smaller processor and less
demanding code of course - as the typical mcu firmware would be.
Basically apart from some exceptions any source working on one
processor can be assembled into code for another one; and the
exceptions are not bulky, though critical - like some handlers within
the supervisor/hypervisor code, task switching, in general dealing
with exceptions is highly processor dependent - though in large part
the code which does the handling is still processor independent, one
has to go through it manually.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Sat, 27 May 2017 21:05:18 +0000, Grant Edwards wrote:

> I vaguely remember one product many years ago that used some sort of
> configuration file to define the mnemonics and instruction format for
> each architecture.  The base "executable" for the assembler itself was
> universal.

The Cross-32 Meta-assembler worked like that.  Configuration tables 
described the instruction word formats and the mnemonics you were going 
to use.  The unconfigured part of the program supplied the symbol-table 
handling and the macro facility.  Provided very powerful assembly-time 
address processing.  It worked very well on most architectures, except 
for some DSPs that packed several instructions into single machine words, 
so you couldn't summarize the format of a line of assembly code.  
ADSP-2100 rings a bell here, though I may have mis-remembered.  Back when 
development software was expensive it was a boon to have to spend that 
kind of money only once.

On 28.5.2017 г. 00:17, Les Cargill wrote:
> rickman wrote:
>> Someone in another group is thinking of using a portable assembler
>> to write code for an app that would be ported to a number of
>> different embedded processors including custom processors in FPGAs.
>> I'm wondering how useful this will be in writing code that will
>> require few changes across CPU ISAs and manufacturers.
>>
>> I am aware that there are many aspects of porting between CPUs that
>> is assembly language independent, like writing to Flash memory.  I'm
>> more interested in the issues involved in trying to use a universal
>> assembler to write portable code in general.  I'm wondering if it
>> restricts the instructions you can use or if it works more like a
>> compiler where a single instruction translates to multiple target
>> instructions when there is no one instruction suitable.
>>
>> Or do I misunderstand how a portable assembler works?  Does it
>> require a specific assembly language source format for each target
>> just like using the standard assembler for the target?
>>
>
> That's what C is for.

Or Basic. Or Fortran etc.

However, they are by far not what a "portable assembler" - existing
under the name Virtual Processor Assembler in our house is.
And never will be, like any high level language C is yet another
phrase book - convenient when you need to do a quick interaction
when you don't speak the language - and only then.

>
> This being said, I've been doing this for
> 37 years and have only a few times seen an actual need for
> portability - usually, the new hardware is so radically
> different that porting makes little sense.
>

The need for portability arises when you have megabytes of
sources which are good and need to be moved to another, better
platform. For smallish projects - anything which would fit in
an MCU flash - porting is likely a waste of time, rewriting it
for the new target will be faster if done by the same person
who has already done it once.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Sat, 27 May 2017 21:05:18 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2017-05-27, rickman <gnuarm@gmail.com> wrote:
>
>> Someone in another group is thinking of using a portable assembler

The closest I can think of is called "C" :-)

>You'll have to ask them what they mean by "portable assembler".
>
>The only "portable assemblers" I've ever seen were frameworks that let
>you build multiple CPU-specific assemblers from a single source tree.
>
>I vaguely remember one product many years ago that used some sort of
>configuration file to define the mnemonics and instruction format for
>each architecture.  The base "executable" for the assembler itself was
>universal.

I have written several (cross)assemblers and disassemblers for various
platforms using some sort of instruction tables. This works well with
some regular instruction sets, such as PDP-11, VAX and 68K and to a
degree with DG Nova.  

Other architectures are so seriously oddball that you can only handle
a small subset with some general purpose instruction set description
language. You still had to provide hard coded assembly/disassembly
routines for a large number of instructions, especially privileged
instructions (which were often added to the instruction set later on
and then needed to find free op-codes).

>But that was simply an implementaiton detail.  You still had to write 
>seperate source code for each CPU using that CPU's instruction set.
>When you were using it, it wasn't any different than using a set of
>seperate assemblers that shared a common macro/directive processor. 

Absolutely true.

In addition, some general purpose (dis)assemblers, such as the GNU
tools define source and destination order in a particular way, why the
native assembler may use different order for source and destination
operands.

>
>> to write code for an app that would be ported to a number of
>> different embedded processors including custom processors in FPGAs.
>> I'm wondering how useful this will be in writing code that will
>> require few changes across CPU ISAs and manufacturers.
>>
>> I am aware that there are many aspects of porting between CPUs that
>> is assembly language independent, like writing to Flash memory.  I'm
>> more interested in the issues involved in trying to use a universal
>> assembler to write portable code in general.
>
>You'll have to provide a reference to such a "universal assembler if
>you want any real answers.
>
>> I'm wondering if it restricts the instructions you can use or if it
>> works more like a compiler where a single instruction translates to
>> multiple target instructions when there is no one instruction
>> suitable.
>
>AFAIK, you still have to write seperate source code for each CPU
>instruction set.
>
>> Or do I misunderstand how a portable assembler works?  Does it
>> require a specific assembly language source format for each target
>> just like using the standard assembler for the target?
>
>That's all I've ever run across in 35 years of low-level embedded
>work...

Dimiter_Popoff <dp@tgi-sci.com> wrote:
> The need for portability arises when you have megabytes of
> sources which are good and need to be moved to another, better
> platform. For smallish projects - anything which would fit in
> an MCU flash - porting is likely a waste of time, rewriting it
> for the new target will be faster if done by the same person
> who has already done it once.

Back in the 80s, lots of software was written in assembly.  But it was
common for software to be cross-platform - a popular game might come out for
half a dozen or more machines, using Z80, 6502, 68K, 8086, 6809, etc.

Obviously 'conversion' involved more than just the instruction set - parts
had to be written for the memory available and make use of the platform's
graphics capabilities (which could be substantially different).  But were
there tools to handle this, or did the programmers sit down and rewrite the
assembly from scratch for each version?

Theo

On 2017-05-27, upsidedown@downunder.com <upsidedown@downunder.com> wrote:

>>But that was simply an implementaiton detail.  You still had to write 
>>seperate source code for each CPU using that CPU's instruction set.
>>When you were using it, it wasn't any different than using a set of
>>seperate assemblers that shared a common macro/directive processor. 
>
> Absolutely true.
>
> In addition, some general purpose (dis)assemblers, such as the GNU
> tools define source and destination order in a particular way, why the
> native assembler may use different order for source and destination
> operands.

I always found it exceedingly odd that with the Gnu assembler, some of
the meta-level syntax/semantics differed from one target to the next
(e.g. comment delimiters, data directives, etc.).

-- 
Grant

On 2017-05-27, Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

> Back in the 80s, lots of software was written in assembly.  But it was
> common for software to be cross-platform - a popular game might come out for
> half a dozen or more machines, using Z80, 6502, 68K, 8086, 6809, etc.
>
> Obviously 'conversion' involved more than just the instruction set - parts
> had to be written for the memory available and make use of the platform's
> graphics capabilities (which could be substantially different).  But were
> there tools to handle this, or did the programmers sit down and rewrite the
> assembly from scratch for each version?

Usually the latter.

There were tools that were supposed to help you do things like port
8080 assmebly language programs to the 8086, but from what I
read/heard they didn't turn out to be very useful in the real world.

-- 
Grant