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.
Portable Assembly
Started by ●May 27, 2017
Reply by ●May 28, 20172017-05-28
Reply by ●May 28, 20172017-05-28
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
Reply by ●May 28, 20172017-05-28
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.
Reply by ●May 28, 20172017-05-28
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
Reply by ●May 28, 20172017-05-28
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.
Reply by ●May 28, 20172017-05-28
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.
Reply by ●May 28, 20172017-05-28
Am 27.05.2017 um 23:31 schrieb Dimiter_Popoff:> On 28.5.2017 г. 00:17, Les Cargill wrote: >> rickman wrote: >>> 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.So, then, what is a portable assembler? One major variable of a processor architecture is the number of registers, and what you can do with them. On one side of the spectrum, we have PICs or 6502 with pretty much no registers, on the other side, there's things like x86_64 or ARM64 with plenty 64-bit registers. Using an abstraction like C to let the compiler handle the distinction (which register to use, when to spill) sounds like a pretty good idea to me. If you were more close to assembler, you'd either limit yourself to an unuseful subset that works everywhere, or to a set that works only in one or two places. Stefan
Reply by ●May 28, 20172017-05-28
On 28.5.2017 г. 19:45, Stefan Reuther wrote:> Am 27.05.2017 um 23:31 schrieb Dimiter_Popoff: >> On 28.5.2017 г. 00:17, Les Cargill wrote: >>> rickman wrote: >>>> 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. > > So, then, what is a portable assembler?One which is not tied to a particular architecture, rather to an idealized machine model. It makes sense to use this assuming that processors evolve towards better, larger register sets - which has been the case last few decades. It would be impractical to try to assemble something written once for say 68k and then assemble it for a 6502 - perhaps doable but insane.> > One major variable of a processor architecture is the number of > registers, and what you can do with them. On one side of the spectrum, > we have PICs or 6502 with pretty much no registers, on the other side, > there's things like x86_64 or ARM64 with plenty 64-bit registers. Using > an abstraction like C to let the compiler handle the distinction (which > register to use, when to spill) sounds like a pretty good idea to me.Using a phrase book is of course a good idea if you want to conduct a quick conversation. It is a terrible idea if you try to use the language for years and choose to stay confined within the phrases you have in the book. > If you were more close to assembler, you'd either limit yourself to an > unuseful subset that works everywhere, or to a set that works only in > one or two places. Like I said before, there is no point to write code which can work on any processor ever made. I have no time to waste on that, I just need my code to be working on what is the best silicon available. This used to be 68k, now it is power. You have to program with some constraints - e.g. knowing that the "assembler" (which in reality is more a compiler) may use r3-r4 as it wishes and not preserve them on a per line basis etc. Since the only person who could make a comparison between a HLL and my vpa is me, I can say it has made me orders of magnitude more efficient. Obviously you can take my word for that or ignore it, I can only say what I know. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●May 28, 20172017-05-28
On 2017-05-28, Stefan Reuther <stefan.news@arcor.de> wrote:> Am 27.05.2017 um 23:31 schrieb Dimiter_Popoff: >> On 28.5.2017 г. 00:17, Les Cargill wrote: >>> rickman wrote: >>>> 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. > > So, then, what is a portable assembler?1) It's what Unicorns use when writing code to run the automation equipment used by Elves to mass-produce cookies inside hollow trees. 2) It's a trigger phrase that indicates the person using it is delusional and is about to lure you into a time-sink of relativistic proportions. If I were you, I'd either smile politely and change the topic or just turn and run. -- Grant
Reply by ●May 28, 20172017-05-28
On 29.5.2017 г. 04:59, Grant Edwards wrote:> On 2017-05-28, Stefan Reuther <stefan.news@arcor.de> wrote: >> Am 27.05.2017 um 23:31 schrieb Dimiter_Popoff: >>> On 28.5.2017 г. 00:17, Les Cargill wrote: >>>> rickman wrote: >>>>> 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. >> >> So, then, what is a portable assembler? > > 1) It's what Unicorns use when writing code to run the automation > equipment used by Elves to mass-produce cookies inside hollow trees. > > 2) It's a trigger phrase that indicates the person using it is > delusional and is about to lure you into a time-sink of > relativistic proportions. > > If I were you, I'd either smile politely and change the topic or just > turn and run. >Oh smile as much as you want. Then try to match 10% of what I have made and try to smile again.
