Project with "IF" function and timer

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.

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

I was also more a Z80 than a 6502 person in those days as well.

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.

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

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.

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.

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

Put it this way - it's not an architecture I choose for my designs.

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.

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.

--- clip clip ---

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?

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.

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

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

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

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

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.

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

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

only in a course in school, . . . a long, long time ago. ed

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.