Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26645 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2017-05-27 15:39 -0400 |
| Last post | 2017-06-07 02:02 -0400 |
| Articles | 20 on this page of 95 — 24 participants |
Back to article view | Back to comp.arch.embedded
Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-27 15:39 -0400
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:05 +0000
Re: Portable Assembly Mel Wilson <mwilson@the-wire.com> - 2017-05-27 21:29 +0000
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 00:36 +0300
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:56 +0000
Re: Portable Assembly Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-05-28 14:36 +0200
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 09:53 +0200
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-05-27 16:17 -0500
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 00:31 +0300
Re: Portable Assembly Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-05-27 22:52 +0100
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-27 21:58 +0000
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 07:37 +0300
Re: Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-28 01:28 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-28 07:33 +0100
Re: Portable Assembly rickman <gnuarm@gmail.com> - 2017-05-28 03:22 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-28 08:49 +0100
Re: Portable Assembly upsidedown@downunder.com - 2017-05-28 15:03 +0300
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-05-28 12:26 +0300
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 01:04 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 10:43 +0200
Re: Portable Assembly Anssi Saari <as@sci.fi> - 2017-05-31 10:19 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-31 01:49 -0700
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-05-31 15:56 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 02:33 -0700
Re: Portable Assembly upsidedown@downunder.com - 2017-05-29 23:46 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 13:54 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 15:52 -0700
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 02:14 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 17:14 -0700
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 03:38 +0300
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 18:42 -0700
Re: Portable Assembly Stefan Reuther <stefan.news@arcor.de> - 2017-05-28 18:45 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 20:47 +0300
Re: Portable Assembly Stefan Reuther <stefan.news@arcor.de> - 2017-05-29 18:43 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 10:23 -0700
Re: Portable Assembly "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-05-30 16:31 +0200
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-29 01:59 +0000
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 05:21 +0300
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-05-28 22:04 -0500
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-29 02:57 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 11:00 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 15:08 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 15:06 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-29 20:02 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-29 23:13 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-30 16:53 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-05-31 11:36 +0200
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-01 22:43 +0300
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-02 13:27 +0200
Re: Portable Assembly Grant Edwards <invalid@invalid.invalid> - 2017-05-29 13:48 +0000
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-05-27 15:46 -0700
Re: Portable Assembly Tim Wescott <tim@seemywebsite.really> - 2017-05-28 23:59 -0500
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-28 00:23 +0300
Re: Portable Assembly jim.brakefield@ieee.org - 2017-05-27 16:54 -0700
Re: Portable Assembly Walter Banks <walter@bytecraft.com> - 2017-05-29 17:23 -0400
Re: Portable Assembly "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2017-06-02 17:03 +0200
Re: Portable Assembly Mike Perkins <spam@spam.com> - 2017-06-05 15:39 +0100
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-05 18:10 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-05 09:10 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-06 00:24 -0400
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-06 11:05 +0200
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-06 07:03 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-06 16:58 +0200
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-06-06 21:26 +0300
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-06 16:42 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-06 23:16 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-08 06:38 -0400
Re: Portable Assembly Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-08 15:58 +0300
Re: Portable Assembly upsidedown@downunder.com - 2017-06-08 21:34 +0300
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-06-10 15:27 -0500
Re: Portable Assembly Les Cargill <lcargill99@comcast.com> - 2017-06-10 15:23 -0500
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-08 14:50 +0100
Re: Portable Assembly Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-06-08 17:38 +0300
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-08 16:37 +0100
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-09 14:14 -0400
Re: Portable Assembly Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-09 22:25 +0100
Re: Portable Assembly Clifford Heath <no.spam@please.net> - 2017-06-10 09:54 +1000
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-09 00:06 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-09 22:14 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-09 22:50 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-10 21:01 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-11 00:39 -0700
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-12 23:27 -0400
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-12 22:42 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-13 14:24 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-13 21:57 -0700
Re: Portable Assembly Reinhardt Behm <rbehm@hushmail.com> - 2017-06-14 13:26 +0800
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-13 23:58 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-19 06:48 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-19 16:45 -0700
Re: Portable Assembly Ed Prochak <edprochak@gmail.com> - 2017-06-20 15:07 -0700
Re: Portable Assembly Don Y <blockedofcourse@foo.invalid> - 2017-06-21 07:37 -0700
Re: Portable Assembly David Brown <david.brown@hesbynett.no> - 2017-06-07 09:20 +0200
Re: Portable Assembly Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-06-07 00:30 +0300
Re: Portable Assembly George Neuner <gneuner2@comcast.net> - 2017-06-07 02:02 -0400
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-27 15:39 -0400 |
| Subject | Portable Assembly |
| Message-ID | <ogckfb$qcb$1@dont-email.me> |
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
[toc] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-27 21:05 +0000 |
| Message-ID | <ogcpme$6s7$1@reader1.panix.com> |
| In reply to | #26645 |
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
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2017-05-27 21:29 +0000 |
| Message-ID | <ogcr38$dce$1@dont-email.me> |
| In reply to | #26646 |
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.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2017-05-28 00:36 +0300 |
| Message-ID | <m9rjicposqrmcfou9k8ksegb7jh7bnp60j@4ax.com> |
| In reply to | #26646 |
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...
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-27 21:56 +0000 |
| Message-ID | <ogcsmr$1ed$1@reader1.panix.com> |
| In reply to | #26651 |
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
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2017-05-28 14:36 +0200 |
| Message-ID | <eovuhrF2tjkU1@mid.dfncis.de> |
| In reply to | #26653 |
Am 27.05.2017 um 23:56 schrieb Grant Edwards: > 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.). 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-29 09:53 +0200 |
| Message-ID | <oggjqd$14m$1@dont-email.me> |
| In reply to | #26651 |
On 27/05/17 23:36, upsidedown@downunder.com wrote: > 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" :-) > 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.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-05-27 16:17 -0500 |
| Message-ID | <ogcq6o$cf0$1@dont-email.me> |
| In reply to | #26645 |
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
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-05-28 00:31 +0300 |
| Message-ID | <ogcr17$ft7$1@dont-email.me> |
| In reply to | #26647 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Theo Markettos <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2017-05-27 22:52 +0100 |
| Message-ID | <jGf*k1Nsw@news.chiark.greenend.org.uk> |
| In reply to | #26649 |
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
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-27 21:58 +0000 |
| Message-ID | <ogcsqq$1ed$2@reader1.panix.com> |
| In reply to | #26652 |
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
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2017-05-28 07:37 +0300 |
| Message-ID | <cmkkiclelh2bd6h163tt4pv2dnspa10afn@4ax.com> |
| In reply to | #26654 |
On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote: >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. 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 ... .
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-28 01:28 -0400 |
| Message-ID | <ogdmvd$l7f$3@dont-email.me> |
| In reply to | #26663 |
upsidedown@downunder.com wrote on 5/28/2017 12:37 AM: > On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards > <invalid@invalid.invalid> wrote: > >> 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. > > 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 ... 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
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-05-28 07:33 +0100 |
| Message-ID | <9buWA.82931$B6.76560@fx02.am4> |
| In reply to | #26663 |
On 28/05/17 05:37, upsidedown@downunder.com wrote: > On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards > <invalid@invalid.invalid> wrote: > >> 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. > > 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 ... I only saw the assembly level compatibility claims. I did see the claims that the 80286 and 80386(!) would be completely compatible.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-05-28 03:22 -0400 |
| Message-ID | <ogdtkf$67i$1@dont-email.me> |
| In reply to | #26665 |
Tom Gardner wrote on 5/28/2017 2:33 AM: > On 28/05/17 05:37, upsidedown@downunder.com wrote: >> On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards >> <invalid@invalid.invalid> wrote: >> >>> 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. >> >> 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 ... > > I only saw the assembly level compatibility claims. > > I did see the claims that the 80286 and 80386(!) would > be completely compatible. 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
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-05-28 08:49 +0100 |
| Message-ID | <divWA.149308$lG2.91564@fx11.am4> |
| In reply to | #26666 |
On 28/05/17 08:22, rickman wrote: > Tom Gardner wrote on 5/28/2017 2:33 AM: >> On 28/05/17 05:37, upsidedown@downunder.com wrote: >>> On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards >>> <invalid@invalid.invalid> wrote: >>> >>>> 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. >>> >>> 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 ... >> >> I only saw the assembly level compatibility claims. >> >> I did see the claims that the 80286 and 80386(!) would >> be completely compatible. > > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2017-05-28 15:03 +0300 |
| Message-ID | <o2dlic9c0dmcoog0v79ngomgdukk2iummj@4ax.com> |
| In reply to | #26666 |
On Sun, 28 May 2017 03:22:04 -0400, rickman <gnuarm@gmail.com> wrote: >Tom Gardner wrote on 5/28/2017 2:33 AM: >> On 28/05/17 05:37, upsidedown@downunder.com wrote: >>> On Sat, 27 May 2017 21:58:50 +0000 (UTC), Grant Edwards >>> <invalid@invalid.invalid> wrote: >>> >>>> 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. >>> >>> 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 ... >> >> I only saw the assembly level compatibility claims. I am referring to times long before you could get any usable information even with NDA. >> >> I did see the claims that the 80286 and 80386(!) would >> be completely compatible. > >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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2017-05-28 12:26 +0300 |
| Message-ID | <oge4t2$p80$1@dont-email.me> |
| In reply to | #26654 |
On 28.5.17 00:58, Grant Edwards wrote: > 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. 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
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2017-05-28 01:04 +0300 |
| Message-ID | <ogcsvk$ocs$1@dont-email.me> |
| In reply to | #26652 |
On 28.5.2017 г. 00:52, Theo Markettos wrote: > 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 > 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/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-29 10:43 +0200 |
| Message-ID | <oggmpn$arm$1@dont-email.me> |
| In reply to | #26652 |
On 27/05/17 23:52, Theo Markettos wrote: > 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? > 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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web