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
Reply to
rickman
Loading thread data ...

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.

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

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

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

--
Grant
Reply to
Grant Edwards

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
Reply to
Les Cargill

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

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.

Reply to
Mel Wilson

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.

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

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

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

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.

Reply to
upsidedown

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

Reply to
Theo Markettos

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
Reply to
Grant Edwards

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
Reply to
Grant Edwards

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

formatting link
. 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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

te

l
s

to

le

ne

the

]>ported to a number of different embedded processors including custom proc essors in FPGAs

It's possible to do direct threaded code in C. For small projects, the num ber of threaded code routines is small and highly application specific. So all the thread code segments are very portable and the debugging is in t he threaded code routines (e.g. one can perfect the application in C on a P C and then migrate to any number of custom ISAs).

That said, am currently creating a system of symbolic constants for all the op-codes and operand values (using VHDL and for each specific ISA). One c an create symbolic constants for various locations in the code (and manuall y update the constants as code gets inserted or deleted). Per-opcode funct ions can be defined that make code generation less troublesome. The code ( either constant expressions or function calls) is laid out as initializatio n for the instruction memory. Simulation can be used to debug the code and the ISA. A quick two step process: edit the code and run the simulator.

One can also write a C or any other language program that generates the bin ary code file which is then inserted into FPGA RAM during the FPGA compile step. Typically one writes a separate function for each op-code or label g enerator (and for each ISA). Two passes through all the function calls (e. g. the application program) first pass to generate the labels and the secon d pass to generate the binary file. For use with FPGA simulation this is a three step process: edit the application program, run the binary file gene rator and run the FPGA simulator.

The preferred solution is to support label generators in the memory initial ization sections of the VHDL or Verilog code. Would be very interested if someone has managed to do label generators?

Reply to
jim.brakefield

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 ... .
Reply to
upsidedown

snipped-for-privacy@downunder.com wrote on 5/28/2017 12:37 AM:

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
Reply to
rickman

I only saw the assembly level compatibility claims.

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

Reply to
Tom Gardner

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
Reply to
rickman

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.

Reply to
Tom Gardner

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
Reply to
Tauno Voipio

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

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.

Reply to
upsidedown

Am 27.05.2017 um 23:56 schrieb Grant Edwards:

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.

Reply to
Hans-Bernhard Bröker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.