You can write Fortran in any language?  So what'syour point?

	--John

On Friday 11 July 2003 13:04 pm, nobodyo@nobo... wrote:
>  Hi,
>
>  under http://www.ioccc.org/years.html you can find good examples of C-Code
> which can't be understood without the explanation.
>
>  One example:
>
>  #include <stdio.h>
>  int l;int main(int o,char **O,
>  int I){char c,*D=O[1];if(o>0){
>  for(l=0;D[l              ];D[l
>  ++]-){D   [l++]-0;D[l]->  110;while   (!main(0,O,l))D[l]
>  +=   20;   putchar((D[l]+1032)
>  /20   )   ;}putchar(10);}else{
>  c=o+     (D[I]+82)%10-(I>l/2)*
>  (D[I-l+I]+72)/10-9;D[I]+=I<0?0
>
>  :!(o=main(c/10,O,I-1))*((c+999
>
>  )%10-(D[I]+92)%10);}return o;}
>
>  This program runs normally on any ANSI C compiler and is ASCII dependent.
>  The source code is nice, compact, and self documenting
>  as all good programs should be!  :-)
>
>  Regards
>
>  Rolf F.
>
>
>
>
>
> 
>
>
>
>
>
>
>  .
>
>
>
>  

<nobodyo@nobo...> wrote:

> under http://www.ioccc.org/years.html you can find
good examples of
> C-Code which can't be understood without the explanation.
> 
> One example:
> 
> #include <stdio.h>
> int l;int main(int o,char **O,
> int I){char c,*D=O[1];if(o>0){

That's useless for this discussion. Nobody writes code like this,
and of course it's also possible to construct a similar example in
assembler.

On Fri, 11 Jul 2003 07:23:58 -0000, andrew wrote:

>--- In msp430@msp4..., onestone
<onestone@b...> wrote:
>> Sorry if I confused Andrew, and believe me I'm not having a dig at

>> Salvo. My point is simple, you used Salvo as an example of C vs 
>> assembler, but it is a different entity.
>
>Maybe I need to re-read the earlier posts .. I don't understant why
>Salvo is a different entity, in light of the fact that it does a lot
>of "work" that would otherwise be done by code the applications
>programmer might write him/herself, e.g. timers to run various
>processes at different rates.

Probably because operating system routines encapsulate a rather
portable-enriched share of algorithms, as compared to a complete
application of which the operating system portion is only a
part.  Queue handling, for example, can be made very portable.
By comparison, it's more difficult to make gated integrator
timing code quite as portable.

In other words, there's some routines which can be designed well
for portability and some which are more coupled to the specific
situation.  And when you select out the collection of them which
can go under the heading of "operating system" you tend to self
select a portable-enriched grouping in doing so.

Jon

--- In msp430@msp4..., Jonathan Kirwan <jkirwan@e...> wrote:
> >Maybe I need to re-read the earlier posts .. I
don't understant why
> >Salvo is a different entity, in light of the fact that it does a 
lot
> >of "work" that would otherwise be
done by code the applications
> >programmer might write him/herself, e.g. timers to run various
> >processes at different rates.
> 
> Probably because operating system routines encapsulate a rather
> portable-enriched share of algorithms, as compared to a complete
> application of which the operating system portion is only a
> part.  Queue handling, for example, can be made very portable.
> By comparison, it's more difficult to make gated integrator
> timing code quite as portable.
> 
> In other words, there's some routines which can be designed well
> for portability and some which are more coupled to the specific
> situation.  And when you select out the collection of them which
> can go under the heading of "operating system" you tend to self
> select a portable-enriched grouping in doing so.

OK, now I understand what Al what getting at. Thanks for a different 
perspective / presentation.

My solution for making portable such non-portable, hardware-dependent 
code really boils down to conditionally compiling different versions 
based on the hardware target.

My approach to writing such routines (e.g. your gated integrator 
timing code example) would be almost always to write it in C first, 
and examine the compiler's output. If it's acceptable, I'd leave
it 
at that. If not, I'd probably re-code directly in assembly. Some 
compilers are really efficient, though one sometimes has to "see 
things their way" to get the best results (speed and/or size).

But I'd probably keep the C "template" just to speed things up
for 
subsequent ports. Having to deal with weird assembly-language issues 
(like the PIC's treatment of status flags when doing subtraction) 
tends to make me go batty -- I'd rather at least have the compiler 
guide me in dealing with simple issues (like branch statements, which 
condition codes to use, function preambles, etc.) than have to learn 
all of that from scratch with each new port. Of course, as I become 
more familiar with a particular instruction set, I'll often go back 
and optimize to get tighter code.

In summary, in those cases where I find assembly is required, I 
almost always start in C, examine listings, and iterate in Assembly 
until I get the result I want. 

As pertains to the topic, I find a mixed C/Assembly approach makes 
for faster results than just pure Assembly.

--Andrew Kalman   aek ... at ... pumpkininc ... dot ... com

>> That's useless for this discussion. Nobody writes code like
this,
and of course it's also possible to construct a similar example in
assembler. <<

Er, I think you'll find that nobodyo's posting was firmly tongue in
cheek! 
It's German humour, man! ;-) 

It brought a smile to my  face anyhow! :-) 


------

<nobodyo@nobo...> wrote:

> under http://www.ioccc.org/years.html you can find
good examples of
> C-Code which can't be understood without the explanation.
> 
> One example:
> 
> #include <stdio.h>
> int l;int main(int o,char **O,
> int I){char c,*D=O[1];if(o>0){

That's useless for this discussion. Nobody writes code like this,
and of course it's also possible to construct a similar example in
assembler.

-

Andreas Schwarz wrote:
> <nobodyo@nobo...> wrote:
> 
> 
>>under http://www.ioccc.org/years.html you can find good examples of
>>C-Code which can't be understood without the explanation.
>>
>>One example:
>>
>>#include <stdio.h>
>>int l;int main(int o,char **O,
>>int I){char c,*D=O[1];if(o>0){
> 
> 
> That's useless for this discussion. Nobody writes code like this,
> and of course it's also possible to construct a similar example in
> assembler.

Perhaps because assembler is inherently cleaner and more readable ;@}

Al

aekalman wrote:

> --- In msp430@msp4..., onestone
<onestone@b...> wrote:
> 
>>Sorry if I confused Andrew, and believe me I'm not having a dig at 
>>Salvo. My point is simple, you used Salvo as an example of C vs 
>>assembler, but it is a different entity.
> 
> 
> 
> Maybe I need to re-read the earlier posts .. I don't understant why
> Salvo is a different entity, in light of the fact that it does a lot
> of "work" that would otherwise be done by code the applications
> programmer might write him/herself, e.g. timers to run various
> processes at different rates.
> 

Hi ANDREW. Salvo is an OS. A collection of specifically (one assumes) 
very well optimised procedures  designed specifically, and almost by 
definition to be portable. It is effectively a function library. It is 
not a language, but an application of a language to achieve a well 
defined result. C and assembler on the other hand are languages, one 
with compound functions, the other little more than a 'humanised' 
instructions set. (well assembler can be little more than a symbolic 
representation of the instruction set, which is a collection of binary 
patterns. The first dual mainframe I worked on didn't use the term 
assembler at all, it called it a 'mnemonic instruction set'). Being 
languages I consider C and assebler tp be more similar to each other 
than either is to Salvo. Basically an application program in many respects.

Al

--- In msp430@msp4..., Andreas Schwarz <andreas-s@w...> wrote:
> ??? Now I'm really confused. Andrew tried to
explain why C was
better
> than assembler for his OS, but nobody was
_comparing_ Salvo with C
or
> assembler.

Basically -- I was pointing out that the much-vaunted portability of
C was a real and considerable benefit in being able to apply the Salvo
RTOS to a variety of different hardware platforms. In Salvo's case,
the portability made a huge difference.

Al's point is that in his opinion, C's portability is overrrated
because it doesn't yield benefits for the sort of applications he
writes, with their inherent constraints on size, power and speed. I
assume he would rate Java's portability as much higher than C's, if
only because Java is not (or should not be :-o ) a language for
embedded systems, with all of the hardware-dependencies that accompany
such systems, and therefore Java applications are free from the
worries of interfacing with real hardware. I confess I don't know
Java, just the hype behind it.

The rest of the discussion seems to have turned to issues of personal
preference, and where it makes sense / is necessary to use Assembly
over C.

At the very least, I hope the thread provided an impetus to the less
experienced programmers here to perhaps learn more Assembly if they
have shied away from it until now ... Assembly certainly has its
place.

--Andrew   aek ... at ... pumpkininc ... dot ... com 

onestone <onestone@ones...> wrote:

> aekalman wrote:
> 
> > --- In msp430@msp4..., onestone <onestone@b...> wrote:
> > 
> >>Sorry if I confused Andrew, and believe me I'm not having a
dig at 
> >>Salvo. My point is simple, you used Salvo as an example of C vs 
> >>assembler, but it is a different entity.
> > 
> > 
> > 
> > Maybe I need to re-read the earlier posts .. I don't understant
why
> > Salvo is a different entity, in light of the fact that it does a lot
> > of "work" that would otherwise be done by code the
applications
> > programmer might write him/herself, e.g. timers to run various
> > processes at different rates.
> > 
> 
> Hi ANDREW. Salvo is an OS. A collection of specifically (one assumes) 
> very well optimised procedures  designed specifically, and almost by 
> definition to be portable. It is effectively a function library. It is
> 
> not a language, but an application of a language to achieve a well 
> defined result. C and assembler on the other hand are languages, one 
> with compound functions, the other little more than a 'humanised'

> instructions set. (well assembler can be little more than a symbolic 
> representation of the instruction set, which is a collection of binary
> 
> patterns. The first dual mainframe I worked on didn't use the term 
> assembler at all, it called it a 'mnemonic instruction set').
Being 
> languages I consider C and assebler tp be more similar to each other 
> than either is to Salvo. Basically an application program in many
> respects.

??? Now I'm really confused. Andrew tried to explain why C was better
than assembler for his OS, but nobody was _comparing_ Salvo with C or
assembler.

Howdy,

I thought I'd put my oar in the water on this subject, I'm not a 
software guru, I'm basically a Power Electronics Consultant who 
learned programming to do my job better.  I've only worked on small 
to medium complexity control software for small to medium volume 
products.  I program in Assembly, Forth and C and the highest volume 
product that has suffered my programming attention was done in Forth 
and has (so far) been cloned to the level of only about 60K (not 
ready for prime time).  The biggest factor I've seen when you 
compare C to any other language (Assembly included) is that my 
customers demand that I use C.  No matter how annoyingly I whine, 
they want C.  They feel that C is the easiest to support and if I 
get hit by a meteor (or abducted by PETA for eating hamburgers) I'm 
easily replaceable by a C programmer (I think they are cloned as 
well).  They have been told that a C embedded application is easier 
to port than one in Assembly, it doesn't matter the reality, it's 
their perception...and they have the money.  I know this is not a 
sophisticated argument and I apologize if it doesn't elevate the 
discussion but I tend to listen to my customers even when they start 
sounding like Homer Simpson.
I'd like to add that as I've 'lurked' and listen to this
thread I 
appreciate the interesting and informed opinions and enjoy the 
varied and various contibutors.

Regards,
Mark