Portable Assembly

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Portable Assembly

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

--  
Grant






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

Quoted text here. Click to load it

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.

Re: Portable Assembly
On Sat, 27 May 2017 21:05:18 +0000 (UTC), Grant Edwards

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Portable Assembly

Quoted text here. Click to load it

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

Re: Portable Assembly
Am 27.05.2017 um 23:56 schrieb Grant Edwards:

Quoted text here. Click to load it

Yeah, well, that's what you get for trying to emulate a whole bunch of  
different, pre-existing assemblers made by big companies who all excel  
at doing things differently just for the heck of it.  In other words,  
that's the price of fighting an up-hill battle against epidemically  
ingrained not-invented-here syndrome.

Re: Portable Assembly
On 27/05/17 23:36, snipped-for-privacy@downunder.com wrote:
Quoted text here. Click to load it

Sometimes people call C a "portable assembly" - they are wrong.  But one
of the purposes of C is so that you don't /need/ assembly, portable or not.

What has been discussed so far in this branch (I haven't read the whole
thread yet) has been a retargetable assembler - a way to generate an
assembler program for different processors without going through all the
work each time.  Such tools have existed for many years, and are an
efficient way to make an assembler if you need to cover more than one
target.  They don't help much for writing the actual target assembly
code, however - though usually you can share the same directives
(commands for sections, macros, etc.).  GNU binutils "gas" is the most
widely used example.


As far as a portable assembly language is concerned, that does not and
cannot exist.  Assembly language is by definition too tightly connected
to the ISA of the target.  It is possible to have a language that is
higher abstraction than assembler, but still lower level and with
tighter control than C, and which can be translated/compiled to
different target assemblies.  LLVM is a prime example.







Re: Portable Assembly
rickman wrote:
Quoted text here. Click to load it

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

Re: Portable Assembly
On 28.5.2017 ?. 00:17, Les Cargill wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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/





Re: Portable Assembly
Quoted text here. Click to load it

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

Re: Portable Assembly

Quoted text here. Click to load it

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



Re: Portable Assembly
On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards

Quoted text here. Click to load it

In original marketing  material, itt was claimed that the 8086 was
8080 compatible. However, when the opcode tables were released, it was
quite obvious that this was not the case. Then they claimed  assembly
level compatibility ...
.

Re: Portable Assembly
snipped-for-privacy@downunder.com wrote on 5/28/2017 12:37 AM:
Quoted text here. Click to load it

I've never heard they claimed anything other than assembly source  
compatibility.  It would have been very hard to make the 8086 opcode  
compatible with the 8080.  They needed to add a lot of new instructions and  
the 8080 opcodes used nearly all the space.  They would have had to treat  
all the new opcodes as extended opcodes wasting a byte on each one.  Or  
worse, they could have used instruction set modes which would have been a  
disaster.

--  

Rick C

Re: Portable Assembly
On 28/05/17 05:37, snipped-for-privacy@downunder.com wrote:
Quoted text here. Click to load it

I only saw the assembly level compatibility claims.

I did see the claims that the 80286 and 80386(!) would
be completely compatible.


Re: Portable Assembly
Tom Gardner wrote on 5/28/2017 2:33 AM:
Quoted text here. Click to load it

With each other?  Isn't the 386 upwardly compatible with the 286?  I know  
the 286 was upward compatible with the 8086, kinda sorta.  They used modes  
for the different instruction sets and no one liked it.  It was a big PITA  
to switch modes.

--  

Rick C

Re: Portable Assembly
On 28/05/17 08:22, rickman wrote:
Quoted text here. Click to load it

That was the salesman's claims. Your points about modes
were obvious to any engineer that read the (blessedly
short) preliminary data sheets.

Unfortunately my 1978 Intel data book is too early
to contain the 8086, so I can't check it there.



Re: Portable Assembly

Quoted text here. Click to load it

I am referring to times long before you could get any usable
information even with NDA.

Quoted text here. Click to load it

All the x86 series PC processors start in Real86 mode in order to run
the BIOS, it then switches to some more advanced modes, up to included
64 bit modes.

The problem with 286 was that it contained an instruction for going
from Real86 to Protected286 mode. However, there was no direct way of
going back to Real86 apart from doing a reset.

The 386 had things done better and also contained the Virtual86 mode,
usable for running MS-DOS programs (in user mode)..

About 286 between 386 compatibility, the kernel mode was quite
different.

Some have here criticized the concept of mode bits to select between
different instruction sets. For a microprogrammed machine, this just
require a bit more microcode.  

For instance the VAX-11/7xx executed the PDP-11 user mode instructions
quite well. We only had a VAX for which we also did all RSX-11 PDP-11
program development for at least five years. The same user mode
executable executed nicely on a real  PDP-11 as well as on a VAX by
just copying the executable one way or he other.  

The only nuisance was that since the VAX file system used decimal
notation for file version numbers as decimal while a native PDP-11
used octal :-) . Thus, a program compiled on a real PDP-11 rejected
file references like FILE.TXT;9 , but of course, usually the newest
version was needed and hence no explicit version numbers were used on
the command line.  

On IBM mainframes, sometimes previous generation instruction sets were
"emulated" thus allowing the most recent hardware run the previous
generation OS and programs. That emulator might run a two generation
old OS and programs and so on. I have no idea, how much of these older
generation instructions were partially executed on new hardware and
how much was software emulated instruction by instruction.


Re: Portable Assembly
On 28.5.17 00:58, Grant Edwards wrote:
Quoted text here. Click to load it


I have practical experience of porting 8080 (actually 8085) code
to a 8088 (8086 architecture) when the 8086 family was fresh new.
The Intel tool kinda did it, but the resulting code was not good,
so I ended up re-writing the tool output.

IMHO, the best portability with decent run code is with plain C.
If there is assembly code not expressible efficiently with C, it
is so tightly tied with the hardware that it has to be redone anyway.

I ported several embedded systems from 80188 to ARM7TDMI with little  
trouble. Of course, the low-level startup and interrupt handling went
to a total re-build, but other code (several hundreds of kB) went rather
painless from Borland C to GCC.

There was a bit mode work to port from 68k to ARM, due to the different
endianess of the architectures.

--  

-TV

Re: Portable Assembly
On 28.5.2017 ?. 00:52, Theo Markettos wrote:
Quoted text here. Click to load it

I am not aware of tools doing it, they must have been rewritten. The
exception on your list is the 6809, it was source level compatible
to the 6800 (i.e. 6800 code could be assembled into 6809 code, slightly
larger but very similar object code). BTW I still have a 6809 system
working under DPS - emulated as a task in a window, running MDOS09
(which ran on the Exorsiser systems),
http://tgi-sci.com/misc/sc09em.gif. The 6809 assembler is what I grew
up on back in the 80-s.

I may of course be simply unaware of something. I have never looked
into other people's work more than I needed to do what I wanted to
do as fast as I could, many times I may have chosen to reinvent things
simply because this has been the fastest (pre-www) way.

Dimiter

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


Re: Portable Assembly
On 27/05/17 23:52, Theo Markettos wrote:
Quoted text here. Click to load it

Writing a game involves a great deal more than just the coding.
Usually, the coding is in fact just a small part of the whole effort -
all the design of the gameplay, the storyline, the graphics, the music,
the algorithms for interaction, etc., is inherently cross-platform.  The
code structure and design is also mostly cross-platform.  Some parts
(the graphics and the music) need adapted to suit the limitations of the
different target platforms.  The final coding in assembly would be done
by hand for each target.


Site Timeline