Re: Rene can't handle AoA's Success

On Jun 25, 3:52 am, "Wolfgang Kern" <nowh...@xxxxxxxxxxx> wrote:
Randy answered Herbert,

[about: does an ASM-programmer really need to know ..}

Quick show of hands, people: how many of you know how to design your
own CPU or feel this is an important requirement for an assembly
language *programmer*?

Sure not required for the windoze/linus/mac/xbox-PC/EDP world.

Which is the majority of programmers out there.


But the other big (much bigger) market where ASM-coders can find
a living is consumer electronics and all other mass production,

Really?
Though I've actually gone through the process of CPU design myself, at
no point in the 30 years I've been in the embedded design field have I
ever needed to design my own CPU. Indeed, even when working on an
embedded USB host controller chip, my team did *not* design their own
CPU, but used an off-the-shelf core instead. Certainly, there was no
need for the software engineers to be involved in the hardware design
at all. They were given the interface to the hardware (registers and
the like) and wrote device drivers based on those specs. At no time
did they really need to get involved in the design of the controller
chip itself, other than out of personal interest. And that project
represents the *closest* I've ever seen any reasonable project get to
what you're talking about (that is, the software engineers getting
involved in hardware design).

Perhaps you are a bit confused about this because you come at it from
a hardware (EE) perspective and think that software engineers have to
learn everything you know in order to call themselves "assembly
programmers"? The truth is, you've got it backwards -- you're not an
assembly *programmer*, you're a self-taught EE. In order to be able to
call yourself a *programmer* you need to learn what the software
engineers know, not vice-versa.


where cheap single chips are designed for only one special task
and contain hardwired programs.

That's called logic design, not assembly language programming.


Here nobody asks about maintainabilty or readabilty,

If you believe this, you haven't been paying much attention.

in this field
it's much more interesting how many features can be merged in without
expanding costs.

In a tiny corner of the embedded field, perhaps. But you obviously
don't have enough experience outside your tiny realm to have much of
an educated opinion on this, apparently.

Take, for example, healthcare. Lots of embedded products there.
Believe me, they *care* about issues like maintainability and
readability. They care about being able to prove the design is
correct. Yes, cost is less of an object in that area. I'm just
demonstrating that you don't seem to be aware of what's going on in
the embedded field outside your own tiny little area of expertise.
Another example -- nuclear reactor control systems (something I know a
*little* bit about). You better believe they care about such things as
maintainability and reliability. Indeed, it's a hard thing to convince
reactor designers to consider the use of software because they fear
that programmers take the same cavalier attitude that you take. Okay,
reactors are expensive, too. Let's consider something a little
cheaper, say embedded processors in keyboards (yet another thing that
I have a little bit of experience with). If you think that reliability
(e.g., maintainability and readability) of the software are not
important here, consider what happens when you've just burned 1,000
OTPs for a batch of keyboards and discover a bug in the software. Or
worse, you discover the bug *after* shipping those 1,000 keyboards
with the chip soldered into the circuit board. In cases like those,
management starts caring a *lot* about the quality of the keyboard.
And it only takes a few screw-ups like these to pay for the next
larger off-the-shelf CPU that has a few more bytes of ROM so you can
write better quality code.



And don't tell us you've seen this done with C or C++/- or VB.
FPGA'a are a good way to test and emulate, but they are still too
expensive for mass production.

I've seen lots of 8051 designs written with C.
Don't know where you've been.
hLater,
Randy Hyde


.

Relevant Pages

  • [PATCH] [RSDL 6/6] sched: document rsdl cpu scheduler
    ... Add comprehensive documentation of the RSDL cpu scheduler design. ... +A novel design which incorporates a foreground-background descending priority ... +the cpu that it is queued onto also keeps a record of that quota. ...
    (Linux-Kernel)
  • [PATCH] [RSDL-mm 6/6] sched: document rsdl cpu scheduler
    ... Add comprehensive documentation of the RSDL cpu scheduler design. ... +A novel design which incorporates a foreground-background descending priority ... +the cpu that it is queued onto also keeps a record of that quota. ...
    (Linux-Kernel)
  • [PATCH][RSDL-mm 6/6] sched: document rsdl cpu scheduler
    ... Add comprehensive documentation of the RSDL cpu scheduler design. ... +A novel design which incorporates a foreground-background descending priority ... +the cpu that it is queued onto also keeps a record of that quota. ...
    (Linux-Kernel)
  • [PATCH][RSDL-mm 7/7] sched: document rsdl cpu scheduler
    ... Add comprehensive documentation of the RSDL cpu scheduler design. ... +A novel design which incorporates a foreground-background descending priority ... +the cpu that it is queued onto also keeps a record of that quota. ...
    (Linux-Kernel)
  • Re: Is it worth making an 8031/32 board?
    ... I've been using ADSP-21xx since about 1989, ... complex-out FFT on an integer CPU in almost ... So a 20-25 year run with the same basic code design I developed 16-17 ... DSP technical support trying to understand what my 'scope was saying. ...
    (comp.arch.embedded)