Re: port I/O abstraction macros
- From: "Tom Lucas" <news@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 7 Jun 2006 15:34:50 +0100
"Le Chaud Lapin" <unoriginal_username@xxxxxxxxx> wrote in message
news:1149685713.011841.53460@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Tom Lucas wrote:
I see little point in graduating knowing how to write a compiler or
design
an FM radio unless you are directly going into Sony's Radio Compiler
division. Knowing what a compiler does and the sort of tricks current
optimisers play will be more useful in the real world than knowing how to
parse an arithmetic expression. Similarly knowing about RF, demodulation
and
amplifiers is more useful to the real world than an rudimentary FM radio
kit.
There seems to be a bit of a contradiction here. You seem to be saying
that shallow practice is not good (FM kit), but you also seem to be
saying that basic theory (being able to parse arithmetic expressions)
is not good either.
What I'm saying is actually implementing a solution is not necessary and
moves away from the theoretical into the practical. I would also class the
mechanics of parsing an expression as an implementation challange and not
part of the theory of a compiler (although it is an important part of the
solution.)
A person cannot design an FM radio without understanding many aspects
of electronic theory. In the case I was speaking of, the electronics
course gives a bag of components, and a lot of theory. You're expected
to make everything, including the amplifiers, filters, phase-lock loop
(from a pre-packaged VCO), etc. Anyone who had not been paying
attention to the theory would simply not be able to make the radio.
The same course (or the next one) introduces Kalman filtering. It's
not a connect-the-dots type project.
There is certainly value to prove the knowledge gained on the course but
this is simply a practical way of verifying that the exams are setting the
correct questions. My point is that I would regard the radio (and compiler)
construction as a polytechnic activity whereas the universities will be
happy to impart the knowledge academically and test it by exams.
For the compiler, I think it is very important to be able to parse
arithmetic expressions. Knowledge of automata theory can be
invaluable. For my current job, I recently had to make a small
compiler for a stack machine. Here's the tokenizer for lexical
analysis:
Again, I think it's important to understand what the compiler is going to do
and have an idea about how you would approach an expression parser but very
few people actually write a compiler. I would say that for the majority of
graduates the theory behind an abstract generic compiler is enough and
actually writing one is time that could be spent on something else (although
there is some merit in taking on a complex software design task)
<snip code>
I have no clue about optimization, but what I needed to know to make
this compiler can be found in the first few chapters of any compiler
book.
Hence why there isn't a lot of value in writing one unless you actually need
to.
Self-reliance is achieved by focusing on a small bit and
learning that well, than reading the whole book casually and not
remembering anything.
I agree that's true for me but people learn in different ways. I learn by
doing but I know people who can read the book while I do the examples and we
both end up with the same knowledge.
I started dong this long ago after a
converstation I had with a professor just before my graduation. I
asked, "There is so much to learn in the world...is it better to hurry
up and grab what you can and depend on other people for deep insight or
is it bet..." he finished my sentenced quickly and said, "It's better
for you to know." I asked, "But does one person have time in his life
to...?" he says, "Yes." I asked, "Are you sure?" he said, "Yes."
Sure a professor will have plenty of time to know it all - he doesn't have a
manager baying for blood because products in the field crash every 12532th
time they are turned on :-) Philosophically it is better to know the answers
yourself but often it is sufficient to know where you will find the answers.
The more you know the more complete a solution you will find but realism
will always intrude and take away your learning time.
.
- References:
- port I/O abstraction macros
- From: Tom Torfs
- Re: port I/O abstraction macros
- From: DAC
- Re: port I/O abstraction macros
- From: Tom Lucas
- Re: port I/O abstraction macros
- From: Le Chaud Lapin
- Re: port I/O abstraction macros
- From: Tom Lucas
- Re: port I/O abstraction macros
- From: Le Chaud Lapin
- port I/O abstraction macros
- Prev by Date: Re: Coldfire MCF5475 performance question
- Next by Date: Re: Front Panel
- Previous by thread: Re: port I/O abstraction macros
- Next by thread: Re: MCU with CANbus + 10-bit ADC
- Index(es):
Relevant Pages
|