On Sat, 4 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
> 
> > On Thu, 2 Jul 2009, Tamas Rudnai wrote:
> >> I think it is not a win or loose conversation. I love these
> >> conversations too as many times some very important thoughts pulled
> >> out of someones head that would never mentioned otherwise. 
> >> 
> > 
> > Actually I agree with Tamas. 
> > 
> > I find that trying to discuss languages with most people these days
> > tends to boil down to: use C, use C++ or use Java. Not very
> > productive if you're trying to do something better.
> 
> I remember that when I first read about Ada, I thought that this would
> be the future. It didn't become the future... Ada compilers are too
> heavyweight, too complicated, too expensive, too "niche". Probably no
> way to implement a compiler for a small 8bit micro efficiently. 

You forgot the "conformance" aspect. Ada is a registered trademark of the 
US DoD. To write an Ada compiler, the vendor needs (needed?) to jump 
through DoD hoops. The compiler needed to be certified and anyone using 
the compiler could not do DoD work if the certification had expired (they 
had to be recertified every year) without special DoD excemption.

With all this BS going on, it's no wonder Ada never really took off.

> 
> > Remember, the point of a programming language is to allow the user to
> > describe the problem so that the compiler can generate the best code
> > to solve that problem. 
> 
> One thing that's missing in this affirmation is that it's not typically
> about "the compiler can generate the best code". Typically it's foremost
> about describing the problem in an efficient way -- for the programmer.
> The compiler doesn't have to produce the best code possible; it has to
> produce code that's good enough. But it has to make the programmer's job
> easy; this is its main job.
> 

Yes I can see where you are comming from. So what would you say to a 
programmer who points at your generated code and laughing says "I could 
have done that in half the number of machine code instructions" using C. 
If your C "successor" is going to stand any chance of competeing with C, 
it's got to generate code that's at least on a par with it.

> It seems a certain part of the engineering population thinks that ladder
> logic is an adequate way to describe their control problems, yet ladder
> logic compilers are definitely unpopular with the micro crowd. There
> seem to be groups that have different views of what is the easiest way
> to describe a problem.

Yes but most people that like ladder logic are not expert programmers.

> 
> Another thing that's IMO missing in the affirmation above is that it's
> not about "the" problem, it's about "a relevant subset of all
> engineering problems". And here is where the "glorified assembler" (and
> assembler) comes in, with the flexibility to address problems in not yet
> thought-of domains.

But most problems can be broken down into much smaller well defined 
processes such as search, sort, append, remove etc. which a language 
should be able to apply to basic data types such as lists, sets, heaps, 
arrays, strings etc. For any really complex not yet thought-of domains we 
have libraries. I am so fed up with the notion that we need libraries for 
everything, that the language needs to be so rediculasly simply as to not 
be able to understand types such as lists, strings, dynamic array etc. 
when these types are so common and well understood.

> 
> 
> > It is not to micro manage the generation of an executable such that
> > the compiler becomes nothing more than a glorified assembler.
> 
> Hm... With "nothing more than a [...] assembler" you're probably
> correct. OTOH, I don't know of any language in widespread use that is
> "nothing more". (We could probably disagree on what "glorified" means :)
> 
> But if you substitute "nothing more" with "not much more", things are
> not so simple anymore. It is a tricky balance between adaptable and
> standardized, lightweight and powerful, flexible and supporting, almost
> requiring, good practices, universal and highly optimized, allowing
> solutions adequate for every domain and including yet unknown domains,
> ...
> 
> 
> One thing I wonder is why we haven't seen a programming language on
> silicon. Not a Basic interpreter in firmware, but something more
> substantial and efficient, along the lines of the Java micros (that
> never seem to take off). Is this because it produces faster code with
> the same amount of silicon when a compiler optimizes assembly than when
> microcode executes high-level constructs directly?

I think if you look at a high level language like Java or even the 
executable produced by something like a C++ compiler, you will find that 
the native machine code being executed is not the problem - the problem is 
all the dynamic memory management that is going on. Objects being created 
and destroyed just so that trivial operations can be performed without 
impacting on other objects.

Personally I think if you really want to optimise a processor to execute 
high level code more efficiently then it needs an evaluation stack (kind 
of like FORTH) where you can say in one instruction "load the stack with 
this sequence and evaluate it" then let the CPU orchestrate the memory 
accesses to best optimise fetching of values. You could even help it by 
trying to organise variables so that they are near each other in memory.
Two stackes would probably be best, one for manipulating data and one for 
addresses. Offten you don't need to recaclulate an address if you can make 
sure a side effect of the calculation is to put it somewhere where it can 
be used again with minimal effort (e.g. do the calculation in an index 
register and use a different index register for the next address if 
possible).

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist