On 18.6.15 18:32, upsidedown@downunder.com wrote:> On Wed, 17 Jun 2015 21:21:03 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >> On 16.6.15 22:53, upsidedown@downunder.com wrote: >> >> --- clip clip --- >> >>> I still do not understand why intel swathes from octal ( 2 bit opcode >>> and 3 bit destination address and 3 bit source address) to >>> hexadecimal on 8080 and 8085. >> >> >> Intel hired the first software people with IBM background, >> and the culture there used hexadecimal (S/360 & co). >> >> Remember PL/M, a weird descendant of PL/1? > > PL/M-80 was a mature product already in the late 1970's. > > Motorola didn't have any high level languages at that time. I > encountered one strange Pascal implementation for 6809 in 1982, but > unfortunately this was a quite unstable product that couldn�t generate > re-entrant code, so only one task could be written in Pascal, while > all the other tasks had to be written in assembler.PL/M did not generate re-entrant code, either (and it was a pain in the lower back to do so with 8080/8085). -- -TV
Project with "IF" function and timer
Started by ●May 27, 2015
Reply by ●June 18, 20152015-06-18
Reply by ●June 18, 20152015-06-18
upsidedown@downunder.com wrote:> On Wed, 17 Jun 2015 21:21:03 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >> On 16.6.15 22:53, upsidedown@downunder.com wrote: >> >> --- clip clip --- >> >>> I still do not understand why intel swathes from octal ( 2 bit opcode >>> and 3 bit destination address and 3 bit source address) to >>> hexadecimal on 8080 and 8085. >> >> >> Intel hired the first software people with IBM background, >> and the culture there used hexadecimal (S/360 & co). >> >> Remember PL/M, a weird descendant of PL/1? > > PL/M-80 was a mature product already in the late 1970's. > > Motorola didn't have any high level languages at that time. I > encountered one strange Pascal implementation for 6809 in 1982, but > unfortunately this was a quite unstable product that couldn�t generate > re-entrant code, so only one task could be written in Pascal, while > all the other tasks had to be written in assembler. >I think I might have simply made the task switcher run-to-completion/ cooperative multitasking or resorted to the Big Loop. I prefer non-preemptive anyway, but it's gone out of style. -- Les Cargill
Reply by ●June 21, 20152015-06-21
On 18.6.2015 г. 18:32, upsidedown@downunder.com wrote:> On Wed, 17 Jun 2015 21:21:03 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >> On 16.6.15 22:53, upsidedown@downunder.com wrote: >> >> --- clip clip --- >> >>> I still do not understand why intel swathes from octal ( 2 bit opcode >>> and 3 bit destination address and 3 bit source address) to >>> hexadecimal on 8080 and 8085. >> >> >> Intel hired the first software people with IBM background, >> and the culture there used hexadecimal (S/360 & co). >> >> Remember PL/M, a weird descendant of PL/1? > > PL/M-80 was a mature product already in the late 1970's. > > Motorola didn't have any high level languages at that time. I > encountered one strange Pascal implementation for 6809 in 1982, but > unfortunately this was a quite unstable product that couldn¨t generate > re-entrant code, so only one task could be written in Pascal, while > all the other tasks had to be written in assembler. >That Pascal was a monster thing indeed :D. I toyed with it for a few months - was learning the trade back then - and I suppose it is among those which made me see high level languages as a waste of my time :-). It worked fairly well, it has to be said - if you did not mind waiting for half an hour for some not so huge code to compile. I don't remember it for being unstable, may be I had a later version of it (I played with it around 1985-6). But it was (still is for me but that's another animal :-) ...) much much faster to do what you want to do in assembly of course. Around that time Motorola also deployed a Basic, BasicM was the name IIRC - a compiler with many extensions to the language, it was quite usable for some small project to be programmed within a few days. If programming would take significantly longer then the high level would quickly turn from a helping hand into an obstacle (same today with HLL-s but again, see above :-) ). That Basic was written by a guy who was really very good, I have learned a lot at the beginning by just looking at his work (Motorola was publishing many of his sources), Herve Tireford. I think I have taken up his commenting style 1:1, must have evolved over the years but has not changed a lot. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●June 23, 20152015-06-23
On Tuesday, June 16, 2015 at 5:43:14 PM UTC-4, rickman wrote:> How about microcode? Anyone else done that? >only in a course in school, . . . a long, long time ago. ed
Reply by ●June 23, 20152015-06-23
On Tue, 16 Jun 2015 17:43:07 -0400, rickman <gnuarm@gmail.com> wrote:>On 6/16/2015 1:59 PM, Paul Bartlett wrote: >> On Mon, 15 Jun 2015, rickman wrote: >> >>> On 6/15/2015 1:13 PM, Ed Prochak wrote: >>>> On Sunday, June 14, 2015 at 5:50:34 PM UTC-4, rickman wrote: >>>> [] >>>>> >>>>> I don't think he is trying to learn really. I expect this is an >>>>> assignment and he is trying to get something to work as quickly as >>>>> possible. It's not a difficult assignment really, but he needs to >>>>> *learn* about the issues involved rather than just copying code from >>>>> the >>>>> Internet. >> >>>> yes, he seems to be doing on the job learning, poorly. That seems to >>>> be the modern mentality: "I don't need to understand how it works. >>>> I'll just throw code at it until something happens." >>>> >>>> I hope he follows your advice. >>> >>> I remember being in a hurry myself when I was in school. I thought I >>> was learning everything I needed and the actual practice of the craft >>> was just an "exercise". lol. I'm still learning the practice of the >>> craft. >> >> Yes, there are still a few of us old timers out here who not only >> programmed "right down on the iron" in assembly language, we may have >> set bootstrap loaders with toggle switches(!!!) and even did a little >> programming in straight octal/hexadecimal, not even assembly language. >> It seems that these days to too many young whippersnappers, CPUs are >> just black boxes about which they have little understanding how they >> really work under the covers. I wonder even about embedded systems in >> which people code in C? Do they really understand what is going on in >> the hardware layer? Do they need to? > >How about microcode? Anyone else done that?Looking at the Data General Nova instruction set, here was often a 1 to 1 mapping between instruction word bits and individual gates in the data paths or the ALU function selection bits, so one could argue that the Nova instruction set was somewhere between microcode and CISC.
Reply by ●June 24, 20152015-06-24
On Tue, 23 Jun 2015 21:46:44 +0300, upsidedown wrote:> On Tue, 16 Jun 2015 17:43:07 -0400, rickman <gnuarm@gmail.com> wrote: > >>On 6/16/2015 1:59 PM, Paul Bartlett wrote: >>> On Mon, 15 Jun 2015, rickman wrote: >>> >>>> On 6/15/2015 1:13 PM, Ed Prochak wrote: >>>>> On Sunday, June 14, 2015 at 5:50:34 PM UTC-4, rickman wrote: >>>>> [] >>>>>> >>>>>> I don't think he is trying to learn really. I expect this is an >>>>>> assignment and he is trying to get something to work as quickly as >>>>>> possible. It's not a difficult assignment really, but he needs to >>>>>> *learn* about the issues involved rather than just copying code from >>>>>> the >>>>>> Internet. >>> >>>>> yes, he seems to be doing on the job learning, poorly. That seems to >>>>> be the modern mentality: "I don't need to understand how it works. >>>>> I'll just throw code at it until something happens." >>>>> >>>>> I hope he follows your advice. >>>> >>>> I remember being in a hurry myself when I was in school. I thought I >>>> was learning everything I needed and the actual practice of the craft >>>> was just an "exercise". lol. I'm still learning the practice of the >>>> craft. >>> >>> Yes, there are still a few of us old timers out here who not only >>> programmed "right down on the iron" in assembly language, we may have >>> set bootstrap loaders with toggle switches(!!!) and even did a little >>> programming in straight octal/hexadecimal, not even assembly language. >>> It seems that these days to too many young whippersnappers, CPUs are >>> just black boxes about which they have little understanding how they >>> really work under the covers. I wonder even about embedded systems in >>> which people code in C? Do they really understand what is going on in >>> the hardware layer? Do they need to? >> >>How about microcode? Anyone else done that? > > Looking at the Data General Nova instruction set, here was often a 1 > to 1 mapping between instruction word bits and individual gates in the > data paths or the ALU function selection bits, so one could argue that > the Nova instruction set was somewhere between microcode and CISC.Blech! I don't recall which model DG-Nova it was - but I remember having to write assembly code for someone. It was truly a RISC machine: to subtract, for example, you needed to complement and add (I think that resulted in two separate instructions). It must have predated microcode.
Reply by ●June 25, 20152015-06-25
On Wed, 24 Jun 2015 16:47:10 +0000 (UTC), Frank Miles <fpm@u.washington.edu> wrote:>On Tue, 23 Jun 2015 21:46:44 +0300, upsidedown wrote: > >> On Tue, 16 Jun 2015 17:43:07 -0400, rickman <gnuarm@gmail.com> wrote: >> >>>On 6/16/2015 1:59 PM, Paul Bartlett wrote: >>>> On Mon, 15 Jun 2015, rickman wrote: >>>> >>>>> On 6/15/2015 1:13 PM, Ed Prochak wrote: >>>>>> On Sunday, June 14, 2015 at 5:50:34 PM UTC-4, rickman wrote: >>>>>> [] >>>>>>> >>>>>>> I don't think he is trying to learn really. I expect this is an >>>>>>> assignment and he is trying to get something to work as quickly as >>>>>>> possible. It's not a difficult assignment really, but he needs to >>>>>>> *learn* about the issues involved rather than just copying code from >>>>>>> the >>>>>>> Internet. >>>> >>>>>> yes, he seems to be doing on the job learning, poorly. That seems to >>>>>> be the modern mentality: "I don't need to understand how it works. >>>>>> I'll just throw code at it until something happens." >>>>>> >>>>>> I hope he follows your advice. >>>>> >>>>> I remember being in a hurry myself when I was in school. I thought I >>>>> was learning everything I needed and the actual practice of the craft >>>>> was just an "exercise". lol. I'm still learning the practice of the >>>>> craft. >>>> >>>> Yes, there are still a few of us old timers out here who not only >>>> programmed "right down on the iron" in assembly language, we may have >>>> set bootstrap loaders with toggle switches(!!!) and even did a little >>>> programming in straight octal/hexadecimal, not even assembly language. >>>> It seems that these days to too many young whippersnappers, CPUs are >>>> just black boxes about which they have little understanding how they >>>> really work under the covers. I wonder even about embedded systems in >>>> which people code in C? Do they really understand what is going on in >>>> the hardware layer? Do they need to? >>> >>>How about microcode? Anyone else done that? >> >> Looking at the Data General Nova instruction set, here was often a 1 >> to 1 mapping between instruction word bits and individual gates in the >> data paths or the ALU function selection bits, so one could argue that >> the Nova instruction set was somewhere between microcode and CISC. > >Blech! I don't recall which model DG-Nova it was - but I remember having to >write assembly code for someone. It was truly a RISC machine: to subtract, >for example, you needed to complement and add (I think that resulted in >two separate instructions). It must have predated microcode.There is a two bit carry control field in the instruction word, so forcing the CarryIn to 1 you could do 1's complement+1 to get two's complement to complete the subtraction in a single instruction. The instruction set was built around the 74181 ALU.
