On 16/06/15 23:43, rickman 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?You don't /need/ to understand the internal details of the cpu for to program it - you don't even /need/ to understand the ISA or assembly when programming in C. But I believe you can only get the best out of a processor if you are familiar with it's internals. When I am learning a new cpu, I like to do some assembly programming just to get the feel of it, even though my "real" programming is almost always C. When I was learning assembly programming as a teenager, my main platform was a ZX Spectrum with an unreliable taperecorder as storage. I wrote assembly code with paper and pencil, then hand-assembled to hex. To test it, I would first have to write a loader program in Basic, then type in hex. If it failed and hung the system, I had to start from scratch - and the main debugging aid was the sound of the buzzing in the voltage regulator. I think the experience taught me a lot about attention to detail, and step-by-step testing.> > How about microcode? Anyone else done that? >Only in theory, at university. But sometimes I think PIC assembly makes more sense if you think of it as microcode, with the W register being merely an internal holding register.
Project with "IF" function and timer
Started by ●May 27, 2015
Reply by ●June 17, 20152015-06-17
Reply by ●June 17, 20152015-06-17
On 6/17/2015 2:51 AM, David Brown wrote:> On 16/06/15 23:43, rickman 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? > > You don't /need/ to understand the internal details of the cpu for to > program it - you don't even /need/ to understand the ISA or assembly > when programming in C. But I believe you can only get the best out of a > processor if you are familiar with it's internals. When I am learning a > new cpu, I like to do some assembly programming just to get the feel of > it, even though my "real" programming is almost always C. > > When I was learning assembly programming as a teenager, my main platform > was a ZX Spectrum with an unreliable taperecorder as storage. I wrote > assembly code with paper and pencil, then hand-assembled to hex. To > test it, I would first have to write a loader program in Basic, then > type in hex. If it failed and hung the system, I had to start from > scratch - and the main debugging aid was the sound of the buzzing in the > voltage regulator. I think the experience taught me a lot about > attention to detail, and step-by-step testing. > >> >> How about microcode? Anyone else done that? >> > > Only in theory, at university. > > But sometimes I think PIC assembly makes more sense if you think of it > as microcode, with the W register being merely an internal holding register.I worked on an Array processor that had a microcode word over 100 bits wide. Lots of dedicated fields with little encoding. Basically the various control points were controlled directly minimizing prop delays. They had PhDs programming the machine because it was all DSP stuff. Management thought you needed a PhD just to program it, lol, but really they were doing the DSP and anyone could have programmed it.... possibly better. Maybe microcode is not the right word for it. There was no higher level coding. So I guess it was as much VLIW as it was microcode. But I don't think anyone used the term VLIW back then. -- Rick
Reply by ●June 17, 20152015-06-17
On 2015-06-17, David Brown <david.brown@hesbynett.no> wrote:> > You don't /need/ to understand the internal details of the cpu for to > program it - you don't even /need/ to understand the ISA or assembly > when programming in C. But I believe you can only get the best out of a > processor if you are familiar with it's internals. When I am learning a > new cpu, I like to do some assembly programming just to get the feel of > it, even though my "real" programming is almost always C. >That of course assumes your toolchain has hidden all the low level aspects of things like interrupt handling and startup code so that when you write your C language interrupt handler someone else has already written all the low level interrupt wrapper code. (Assuming you aren't using an architecture which does this for you in hardware.) If the level of abstraction provided by the toolkit vendor isn't high enough, it also assumes there's some toolkit provided C language level routines to read/update internal CPU specific registers when required. (And the C language only programmer still needs enough knowledge to know when to call those routines in that case). I think the C language only programmer still needs to know enough to have a feeling for how their C code translates into resources used on the target. For example, when you take an interrupt, how much stack space is used to store the CPU state and how many levels of nested interrupts can you fit into the stack space you have allocated ? Similar type of question for application level recursive routines. Do they have a feeling for how much flash (and SRAM) space they have left or are they going to get a nasty surprise from the linker (or suddenly malfunctioning code) one day ? Do they have any feeling for when things have got big enough that their stack may be about to clobber the top of .bss or the heap ? (Assuming a downwards growing stack and the heap, if used, is placed after .bss.)> When I was learning assembly programming as a teenager, my main platform > was a ZX Spectrum with an unreliable taperecorder as storage. I wrote > assembly code with paper and pencil, then hand-assembled to hex. To > test it, I would first have to write a loader program in Basic, then > type in hex. If it failed and hung the system, I had to start from > scratch - and the main debugging aid was the sound of the buzzing in the > voltage regulator. I think the experience taught me a lot about > attention to detail, and step-by-step testing. >I was also more a Z80 than a 6502 person in those days as well.>> >> How about microcode? Anyone else done that? >> > > Only in theory, at university. > > But sometimes I think PIC assembly makes more sense if you think of it > as microcode, with the W register being merely an internal holding register. >Does (8-bit) PIC assembly _ever_ make sense ? :-) PIC32 (AKA MIPS) is rather nice however, if rather lower level than what I am used to with ARM. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●June 17, 20152015-06-17
On 17/06/15 12:27, Simon Clubley wrote:> On 2015-06-17, David Brown <david.brown@hesbynett.no> wrote: >> >> You don't /need/ to understand the internal details of the cpu for to >> program it - you don't even /need/ to understand the ISA or assembly >> when programming in C. But I believe you can only get the best out of a >> processor if you are familiar with it's internals. When I am learning a >> new cpu, I like to do some assembly programming just to get the feel of >> it, even though my "real" programming is almost always C. >> > > That of course assumes your toolchain has hidden all the low level aspects > of things like interrupt handling and startup code so that when you write > your C language interrupt handler someone else has already written all the > low level interrupt wrapper code. (Assuming you aren't using an > architecture which does this for you in hardware.)Yes, that's correct. Often your RTOS (if you are using one), or "project wizard", sample code, etc., will have these sorts of things in place so that as far as you are concerned, your interrupt handlers are basically normal C functions (possibly with some sort of special marking, keyword, __attribute__, etc.).> > If the level of abstraction provided by the toolkit vendor isn't high > enough, it also assumes there's some toolkit provided C language level > routines to read/update internal CPU specific registers when required. > (And the C language only programmer still needs enough knowledge to know > when to call those routines in that case). > > I think the C language only programmer still needs to know enough to > have a feeling for how their C code translates into resources used > on the target.Again, I don't think you need that to write working code (at least with reasonable tools on a modern processor) - but I think you can write better C code when you know the details of the underlying architecture. This is more important for smaller devices - if you are programming an AVR, you should know that "uint8_t" works faster than "uint16_t", and that you should minimise pointer usage. On larger processors (like ARM), you don't need such details in the same way.> > For example, when you take an interrupt, how much stack space is used to > store the CPU state and how many levels of nested interrupts can you fit > into the stack space you have allocated ? Similar type of question for > application level recursive routines. > > Do they have a feeling for how much flash (and SRAM) space they have left > or are they going to get a nasty surprise from the linker (or suddenly > malfunctioning code) one day ? > > Do they have any feeling for when things have got big enough that their > stack may be about to clobber the top of .bss or the heap ? (Assuming > a downwards growing stack and the heap, if used, is placed after .bss.)These are more issues about the chip, memory and peripherals rather than details of the cpu itself - and low-level programmers must certainly have an understanding of these. But you don't need to know the differences between different types of LD instructions to know about memory layouts.> >> When I was learning assembly programming as a teenager, my main platform >> was a ZX Spectrum with an unreliable taperecorder as storage. I wrote >> assembly code with paper and pencil, then hand-assembled to hex. To >> test it, I would first have to write a loader program in Basic, then >> type in hex. If it failed and hung the system, I had to start from >> scratch - and the main debugging aid was the sound of the buzzing in the >> voltage regulator. I think the experience taught me a lot about >> attention to detail, and step-by-step testing. >> > > I was also more a Z80 than a 6502 person in those days as well.I also used the 6502 on the BBC micro. It was easier to work with, as the BBC had a decent assembler, a good Basic to machine code interface, and reliable storage system (disk drive and/or Econet).> >>> >>> How about microcode? Anyone else done that? >>> >> >> Only in theory, at university. >> >> But sometimes I think PIC assembly makes more sense if you think of it >> as microcode, with the W register being merely an internal holding register. >> > > Does (8-bit) PIC assembly _ever_ make sense ? :-)Put it this way - it's not an architecture I choose for my designs.> > PIC32 (AKA MIPS) is rather nice however, if rather lower level than > what I am used to with ARM.The MIPS architecture is very nice, and better than ARM in some ways. But the PIC32 is not a great implementation - with a combination of poor name (making people think with horror of 8-bit PICs), poor SoC (apparently the 480 Mbps USB is /still/ problematic), and poor tools (using a version of gcc that is intentionally crippled unless you pay Microchip vast sums of money to unlock the software that other people wrote for free). This has pretty much ruined MIPS chances of getting into the mainstream microcontroller market, where they could have competed well with ARM - to the great benefit of customers.> > Simon. >
Reply by ●June 17, 20152015-06-17
On 2015-06-17, upsidedown@downunder.com <upsidedown@downunder.com> wrote:> My original point was about writing a program into memory through > front panel toggle switches without any paper listing. In this case it > is essential that the mode (octal/hex) matches the machine > architecture. Using hex on a PDP-11/8080/Z80 requires remember the > whole 8 or 16 bit opcode. For PDP-11 dual operand instructions, you > only needed to remember a 3 bit opcode, then use the byte/word bit > (most significant bit) the addressing mode (3 bits), (base)register (3 > bits) for the first operand and 3+3 bits for the other operand.In one of the computer architecture classes I once took, we spent several weeks dissecting the PDP-11 instruction format and writing a high-level "VHDL-like" implementation for it. The elegence of the instruction set made a big impression on me at the time (having already dealt with some rather ugly microprocessor instruction sets). The only thing since then that evoked a similar feeling was the TI MSP430. -- Grant Edwards grant.b.edwards Yow! over in west at Philadelphia a puppy is gmail.com vomiting ...
Reply by ●June 17, 20152015-06-17
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? -- -TV
Reply by ●June 17, 20152015-06-17
On Wed, 17 Jun 2015 14:21:48 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>On 2015-06-17, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > >> My original point was about writing a program into memory through >> front panel toggle switches without any paper listing. In this case it >> is essential that the mode (octal/hex) matches the machine >> architecture. Using hex on a PDP-11/8080/Z80 requires remember the >> whole 8 or 16 bit opcode. For PDP-11 dual operand instructions, you >> only needed to remember a 3 bit opcode, then use the byte/word bit >> (most significant bit) the addressing mode (3 bits), (base)register (3 >> bits) for the first operand and 3+3 bits for the other operand. > >In one of the computer architecture classes I once took, we spent >several weeks dissecting the PDP-11 instruction format and writing a >high-level "VHDL-like" implementation for it. The elegence of the >instruction set made a big impression on me at the time (having >already dealt with some rather ugly microprocessor instruction sets). > >The only thing since then that evoked a similar feeling was the TI >MSP430.In the late 1970's I speculated about implementing the VAX-11/780 addressing modes in parallel HW processing units with three (or even 6 for string/packed) addressing mode co-processors on separate boards. Implementing the Texas TMS 9900 architecture with a RAM based register set would be trivial.
Reply by ●June 18, 20152015-06-18
On Wednesday, June 17, 2015 at 2:21:06 PM UTC-4, Tauno Voipio 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? >I have some fond memories of PL/M. I argued at one place that we should use it as or primary language, but C was the new popular language and won out for that rather than technical advantages. I liked PL/M partly because I also liked PL/1. Ed
Reply by ●June 18, 20152015-06-18
Ed Prochak wrote:> On Wednesday, June 17, 2015 at 2:21:06 PM UTC-4, Tauno Voipio 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? >> > I have some fond memories of PL/M. I argued at one place that we should > use it as or primary language, but C was the new popular language and won > out for that rather than technical advantages. > > I liked PL/M partly because I also liked PL/1. > > EdI liked and used it for the same reason. During CP/M time I had a PL/M compiler from a swiss company (name forgotten) which had an impressive optimizer for the Z80 and PL/I-80 from DRI of course. PL/M was interesting for embedded work. But the limited data types (only byte and address, not even negative numbers) made it sometimes hard to use. -- Reinhardt
Reply by ●June 18, 20152015-06-18
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.