Searching \ for ' Elegant way round C scoping problem..?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=c
Search entire site for: 'Elegant way round C scoping problem..?'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] Elegant way round C scoping problem..?'
2000\10\26@115253 by mike

flavicon
face
Am I right in thinking there is no 'nice' solution to this C
problem..?

I want to have a procedure which can access a local variable of its
caller. The procedure is only ever called by the one calling
procedure, so the address of that local variable is known at compile
time.

e.g. :

void subproc(a);
{b+=a;} // I want 'b' to be proc1's local 'b'

void proc1()
{int b=0;subproc(1);subproc(2);}

Obviously this is a trivial example, but a decimal-number print
routine is a good example of where this would be useful, as is
anywhere that you have a few sections of arbitary, identical code you
want to turn into a procedure to save memory. This is purely a code-size issue - I realise could pass subproc a
pointer to b, but that wastes code space as it will always be the
same. Returning the updated value would be another way, again wasteful
and not viable if subproc accessed more than one variable..

I could make b global but that partly defeats the point of having a
high-level language do all the data memory allocation, makes the code
less readable, and wastes data memory if I dedicate a global to it.  This can easily be done in Pascal with nested procs, but as far as I
can see you can't do it in C - can someone prove me wrong ?
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@121549 by Andrew Kunz

flavicon
face
Does this do what you want?

Put the two procedures in a file, called SUB.C for example.

static int b = 0;

static void subproc(a)
    {
    b += a;
    }

void proc (void)
    {
    subproc (1);
    subproc (2);
    }

Now, only routines in SUB.C can see b and subproc.  Subproc has access to b, as
does proc, but nobody else in the world does.

To call proc, you should have a header file SUB.H which contains

    void proc (void);

only in it.

Note that "static" on a function or variable in a file like this makes the
variable scope only the file.  You can't get to it with an extern!


Andy

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@123000 by Bill Westfield

face picon face
   I want to have a procedure which can access a local variable of its
   caller. The procedure is only ever called by the one calling
   procedure, so the address of that local variable is known at compile
   time.

   e.g. :

   void subproc(a);
   {b+=a;} // I want 'b' to be proc1's local 'b'

   void proc1()
   {int b=0;subproc(1);subproc(2);}

How about making your subproc local?:
   void proc1()
   {   int b=0;

       void subproc(a)         /* subproc is local to proc */
          {b+=a;}
       subproc(1);subproc(2);
   }

I didn't look it up, but some languages allow this and the local C
compiler didn't immediately complain about a test case...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@123429 by David Kott

flavicon
face
> Does this do what you want?
>
> Put the two procedures in a file, called SUB.C for example.
>
> static int b = 0;
>
> static void subproc(a)
>      {
>      b += a;
>      }
>
> void proc (void)
>      {
>      subproc (1);
>      subproc (2);
>      }
>
> Now, only routines in SUB.C can see b and subproc.  Subproc has access to
b, as
{Quote hidden}

You are, of course, correct Andy, however he was concerned about RAM usage,
and deprecated the use of global variables.  As I am sure you're aware, the
static storage class specifier still allocates the same amount of RAM as a
similar global variable, it just limits the variable's scope to the
particular compilation unit.

I don't see an elegant solution that doesn't involve some sort of tradeoff
between
1. RAM usage, e.g. static or global variables
2. ROM usage, e.g. inlining subproc's functionality at each call site via a
macro
3. Execution time e.g. assign the value of the argument or a reference to it
at the function's call site.

*shrug*

-d

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@125458 by Andrew Kunz

flavicon
face
If you are using HiTech's PICC, you can get to the variable in assembly using
proc$b as it's name

Andy










David Kott <spam_OUTdkottTakeThisOuTspamTESTPROD.COM> on 10/26/2000 12:33:18 PM

Please respond to David Kott <.....dkottKILLspamspam@spam@testprod.com>








To:      PICLISTspamKILLspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Elegant way round C scoping problem..?








{Quote hidden}

b, as
{Quote hidden}

You are, of course, correct Andy, however he was concerned about RAM usage,
and deprecated the use of global variables.  As I am sure you're aware, the
static storage class specifier still allocates the same amount of RAM as a
similar global variable, it just limits the variable's scope to the
particular compilation unit.

I don't see an elegant solution that doesn't involve some sort of tradeoff
between
1. RAM usage, e.g. static or global variables
2. ROM usage, e.g. inlining subproc's functionality at each call site via a
macro
3. Execution time e.g. assign the value of the argument or a reference to it
at the function's call site.

*shrug*

-d

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@125911 by Bill Westfield

face picon face
> however he was concerned about RAM usage, and deprecated the use of
> global variables.  As I am sure you're aware, the static storage class
> specifier still allocates the same amount of RAM as a similar global
> variable, it just limits the variable's scope to the particular
> compilation unit.

And in what way does a global variable use more RAM than a local
variable, especially on a PIC (with no stack pointer or frames)?
(indeed, the requirement to emulate a stack frame may make local
variables even less efficient than global variables.)

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@130507 by M. Adam Davis

flavicon
face
There is no 'nice' solution to what you are attempting.  It flies against the
idea of programming in C.

If, as you indicate, this secondary function only applies to the primary
function, then why don't you simply inline it.  It will have access to all the
variables (static or otherwise) that the primary has.  You can use control
stuctures to manipulate it just as you would if it were a seperate function.

Is there a compelling reason to seperate these two procedures?

-Adam

Mike Harrison wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@130722 by Andrew Kunz

flavicon
face
The linker will allocate local variables on top of one another.  It knows who
will be active and when, and sort of makes it's own stack of memory at link
time.

When I started doing stuff in C, I was really surprised how much less RAM I was
able to use.

Andy









William Chops Westfield <.....billwKILLspamspam.....CISCO.COM> on 10/26/2000 12:56:49 PM

Please respond to Bill Westfield <EraseMEbillwspam_OUTspamTakeThisOuTcisco.com>








To:      PICLISTspamspam_OUTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Elegant way round C scoping problem..?








> however he was concerned about RAM usage, and deprecated the use of
> global variables.  As I am sure you're aware, the static storage class
> specifier still allocates the same amount of RAM as a similar global
> variable, it just limits the variable's scope to the particular
> compilation unit.

And in what way does a global variable use more RAM than a local
variable, especially on a PIC (with no stack pointer or frames)?
(indeed, the requirement to emulate a stack frame may make local
variables even less efficient than global variables.)

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@130923 by Dipperstein, Michael
face picon face
>And in what way does a global variable use more RAM than a local
>variable, especially on a PIC (with no stack pointer or frames)?
>(indeed, the requirement to emulate a stack frame may make local
>variables even less efficient than global variables.)
>
>BillW

Global variables don't use more RAM then local variables, however
local variables may use the same memory locations as other local
variables.  Global variables may not use the same memory
locations.

-Mike

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@131747 by briang

flavicon
face
In-Reply-To: <@spam@tijgvscsn6kb0f7ng137diript87apv1h5KILLspamspam4ax.com>

Mike Harrison <KILLspammikeKILLspamspamwhitewing.co.uk> wrote:

> I want to have a procedure which can access a local variable of its
> caller. The procedure is only ever called by the one calling
> procedure, so the address of that local variable is known at compile
> time.

On a very small processor like a PIC where you can't implement C
properly the address may well be known at compile time but normally a
local variable is on the stack and thus it's address is not known at
compile time.


> This is purely a code-size issue - I realise could pass subproc a
> pointer to b, but that wastes code space as it will always be the
> same.

In Pascal where nested procedures are allowed this is the way the
compiler would normally do it. But if there was more than one variable
to be accessed it would manage with passing just one pointer. In C the
nearest equivalent would be to put all the variables in a structure and
pass a pointer to the structure.

Brian Gregory.
RemoveMEbriangTakeThisOuTspamcix.co.uk

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@131751 by briang

flavicon
face
In-Reply-To: <CMM.0.90.4.972577720.billw@flipper>

William Chops Westfield <spamBeGonebillwspamBeGonespamcisco.com> wrote:
> How about making your subproc local?:
>     void proc1()
>     {   int b=0;
>
>         void subproc(a)         /* subproc is local to proc */
>            {b+=a;}
>         subproc(1);subproc(2);
>     }
>

Not allowed in C.

Brian Gregory.
TakeThisOuTbriangEraseMEspamspam_OUTcix.co.uk

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@133453 by Bill Westfield

face picon face
We've been known to do things like
#define subproc(a) do { \
                       b += a; \
                  } while (0);

Ie, a macro that looks like a function, with or without it's own private
scope...  (I don't think I'd call this "elegant", though.)

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@135255 by mike

flavicon
face
On Thu, 26 Oct 2000 12:16:01 -0400, you wrote:

>Does this do what you want?
not really - this is little better than using a global as the RAM used
by b cannot be re-used as local storage by other procedures outside of
proc() the only advantage is that you can't accidentally re-use it.
You also need to mess with seperate source files which makes the code
even more unreadable.  
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@135516 by mike

flavicon
face
On Thu, 26 Oct 2000 12:54:36 -0400, you wrote:

>If you are using HiTech's PICC, you can get to the variable in assembly using
>proc$b as it's name
>
>Andy
That's the sort of thing I like to see in C compilers - access to
low-level stuff to allow you to do what you_really_ want! However it's
still not much use for C subprocs, and anyway I'm actually using an
ST7 compiler for the current project :-(

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@135922 by mike

flavicon
face
On Thu, 26 Oct 2000 13:03:44 -0400, you wrote:

>There is no 'nice' solution to what you are attempting.  It flies against the
>idea of programming in C.
>
>If, as you indicate, this secondary function only applies to the primary
>function, then why don't you simply inline it.  It will have access to all the
>variables (static or otherwise) that the primary has.  You can use control
>stuctures to manipulate it just as you would if it were a seperate function.
>
>Is there a compelling reason to seperate these two procedures?
Yes - as I said, code space. In assembly  a common first-pass code squeezing method is to replace
repeated sequences of code with subroutines. This would be more
important in C which is less code-efficient.
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@150727 by M. Adam Davis

flavicon
face
Some compilers will give local variables in seperate functions the same memory
locations to use if it can prove that they will not be called within each other.

-Adam

William Chops Westfield wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\26@150740 by M. Adam Davis

flavicon
face
Well, if you must do this in C then you are simply out of luck.

It sounds like you will either have to
1) deal with some assembly in your C code
2) use a global variable
3) waste some code space

You are trying to do something which C not only doesn't support, but actively
discourages.

-Adam

Mike Harrison wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\27@152548 by Peter L. Peres

picon face
void subproc(int a,int *b)
{
 *b+=<3D>a; // NOTE: WHAT is 3D ? probably tilde or whatnot
} // I want 'b' to be proc1's local 'b'

void proc1()
{
 int b=<3D>0, *bp; // 3D is becoming intriguing (plp)

 bp = &b;

 subproc(1,bp);
 subproc(2,bp);
}

If you only call a subroutine once, you should inline it. In C++ you can
avoid the pointer using the & (reference) operator directly.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservspamTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\10\27@155110 by Bob Ammerman

picon face
>
> If you only call a subroutine once, you should inline it. In C++ you can
> avoid the pointer using the & (reference) operator directly.
>
> Peter

Under the hood C++ treats references as pointers.  What else could they be
:-)


Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservEraseMEspam.....mitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\10\27@201251 by Byron A Jeff

face picon face
>
> In-Reply-To: <CMM.0.90.4.972577720.billw@flipper>
>
> William Chops Westfield <EraseMEbillwspamcisco.com> wrote:
> > How about making your subproc local?:
> >     void proc1()
> >     {   int b=0;
> >
> >         void subproc(a)         /* subproc is local to proc */
> >            {b+=a;}
> >         subproc(1);subproc(2);
> >     }
> >
>
> Not allowed in C.

Actually the truth is closer to not allowed in ANSI standard C. GCC for
example allows for that example above unless the -pedantic flag is
set.

Shocked the heckomers out of me the first one of my students showed me that
it worked.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\10\27@203348 by Bob Ammerman

picon face
----- Original Message -----
From: Byron A Jeff <RemoveMEbyronspam_OUTspamKILLspamCC.GATECH.EDU>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Friday, October 27, 2000 8:10 PM
Subject: Re: Elegant way round C scoping problem..?


{Quote hidden}

that
> it worked.
>
> BAJ

Of course you now insist that your students use -pedantic at all times,
right :-)

Wouldn't want the kids learnin' that non-standard stuff. (unless of course
it comes from M$).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use RemoveMElistservKILLspamspammitvma.mit.edu?body=SET%20PICList%20DIGEST
>
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservSTOPspamspamspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\10\28@050301 by mike

flavicon
face
On Sat, 28 Oct 2000 20:05:31 +0200, you wrote:

>void subproc(int a,int *b)
>{
>  *b+=<3D>a; // NOTE: WHAT is 3D ? probably tilde or whatnot
>} // I want 'b' to be proc1's local 'b'
>
>void proc1()
>{
>  int b=<3D>0, *bp; // 3D is becoming intriguing (plp)
>
>  bp = &b;
>
>  subproc(1,bp);
>  subproc(2,bp);
>}
>
>If you only call a subroutine once, you should inline it.
Of course, although it would be very nice if the compiler would do
this for you automatically and eliminate the parameter passing where
possible. This would make the code more readable - as  a matter of
interest does anyone know of a compiler that does this ?  
> In C++ you can
>avoid the pointer using the & (reference) operator directly.
C is bad enough on small micros - C++ ? Yikes!
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu




2000\10\28@062458 by mike

flavicon
face
On Fri, 27 Oct 2000 20:27:49 -0400, you wrote:

{Quote hidden}

I think it's about time ANSI standardised a 'microcontroller version'
of the C standard. For example, there seems to be as many different ways of handling I/O
as there are compilers!
There are a few other features which would greatly improve things
IMO:
A 24-bit 'medium' data type. I often find that  Ints are too short and
Longs a bit wasteful.

Direct access to the carry flag - very handy for things like rotating
and detecting overflows.
Nested procs (as discussed previously) to save code space.

Auto inlining of procedures that are only called once.
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu




2000\10\28@091814 by Byron A Jeff

face picon face
{Quote hidden}

No. I just plugged that particular hole in my paradigm and make sure to
explain that functions cannot be nested. It's just that before it never
occured to me that it was allowed....

{Quote hidden}

Actually I have a different take on it: C really isn't suitable for embedded
systems programming. It's a general purpose language applied to the task.
What's really needed is an application specfic language for embedded systems
programming.

The students in my Language Design and Implementation class are taking a first
crack at such a language. In the next couple of weeks we'll be soliciting
input from the list once they finish their initial design documents. Here's
the basic elements:

- Event driven. Code is triggered when state conditions are met.
- Embedded data types for common I/O operations including digital I/O, async/
 sync serial, parallel, PWM, ADC, voltage to frequency conversion, timers,
 and others.  These objects have attributes that bind them to particular
 pins. Once configured the I/O objects are accessed as normal variables.
- A future ability will be to construct new/different types of objects from
 the embedded set.

Here's a real brief example that'll map a switch (active low) to an LED
(active high):

------------------------------------
bit switch
  addr=PORTA
  bitnum=4
  dir=in
  onstate=0 // Switch reads as on when it's low
endbit

bit led
  addr=PORTB
  bitnum=0
  dir=out
endbit // Note the default onstate for a bit is high

when switch=ON
  led=ON
endwhen

when switch=OFF
  led=OFF
endwhen
---------------------------------------

It's wordy on purpose, because it's a teaching language. It's also incomplete
because there isn't enough time to cover all the issues in a semester.

Comments? More forthcoming in a week or two...

BAJ

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu




2000\10\29@135519 by Peter L. Peres

picon face
>Under the hood C++ treats references as pointers.  What else could they
>be :-)

Onions ? ;-)

BTW one of the most often seen 'bad C' cases (including by me) come from
people who have done assembly and then try their evil hacks on C, while
ignoring the structured nature of C, which is wrong. It takes time to
shake a habit (speaking from experience).

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\10\29@152304 by Peter L. Peres

picon face
>From: Byron A Jeff <RemoveMEbyronspamspamBeGoneCC.GATECH.EDU>

>Actually I have a different take on it: C really isn't suitable for
>embedded systems programming. It's a general purpose language applied to
>the task.

Afaik C is a systems programming language and was designed as such and for
that purpose. They did not actually know what kind of (PDP) system it was
for so they made some features up on the way. It cannot be an accident
that 90% of the operating systems in common use are written in C or some
dialect thereof. It is not pretty and it allows you to rummage in the
gearbox at will. That's what makes it so different from other 'beautiful'
languages which are less good for systems programming for various reasons.

I think that the highly portable nature of C is due to the machine
independent 'structured assembly language' concept they had to use to
accomodate the wildly varying instruction sets of the PDP machines and
other monsters they were using at the time.

>The students in my Language Design and Implementation class are taking a
>first crack at such a language. In the next couple of weeks we'll be
>soliciting

I think that this is a great learning experience but my comments to the
new language can be summarized in two words:

VHDL and Prolog

However, I'm just a guy.

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\10\29@205033 by Bill Westfield

face picon face
>    Afaik C is a systems programming language and was designed as such and
>    for that purpose. They did not actually know what kind of (PDP) system
>    it was for so they made some features up on the way.
>       :
>    I think that the highly portable nature of C is due to the machine
>    independent 'structured assembly language' concept they had to use to
>    accomodate the wildly varying instruction sets of the PDP machines and
>    other monsters they were using at the time.

I think C was pretty obviously targetted toward the PDP11.  There are
constructs that map directly onto PDP11 architectural features...

Let's not get revisionist, either.  It was "ages" (more than 10 years?)
before C was widely in use on anything BUT PDP11s.  It never hit the PDP-8
at all (AFAIK), wasn't particularly usable on the PDP-10 till after that
architecture's nominal lifetime, and BLISS was heavilly pushed for the Vax.
C was available for CPM machines, but was not a big success.  Much Apple
Mac Software was written in Pascal dialects, and C wasn't used "much" on
Wintel systems till the 386 processor fixed the architectures to be more
C-friendly.  C popularity on microCONTROLLERS postdates THAT - a relatively
recent phenomena indeed.

In a sense, this is the RISC revolution at work.  The way I interpret it,
the idea behind RISC is not to make processor architectures any more
complex that compiler technology can generate good code for (which is
a bit different than just reducing the number of instructions.)

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\10\30@044209 by Alan B. Pearce

face picon face
>Of course you now insist that your students use -pedantic at all times,
>right :-)

Is there not some way of having a system wide default setting that they do not realise exists to enforce it?? Gotta play these students at their own game  ;))

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\30@044625 by mike

flavicon
face
On Sun, 29 Oct 2000 13:08:32 +0200, you wrote:

>>Under the hood C++ treats references as pointers.  What else could they
>>be :-)
>
>Onions ? ;-)
>
>BTW one of the most often seen 'bad C' cases (including by me) come from
>people who have done assembly and then try their evil hacks on C, while
>ignoring the structured nature of C, which is wrong. It takes time to
>shake a habit (speaking from experience).
>
>Peter
Depends on the application. IMO No-one should try using C on a small
micro until they've done a fair bit of assembly first - that way they
get a good feel for the hardware, understand how to best use the
limited resources available, and be able to tell if the compiler is
generating sensible-sized code.
I'd bet that any assembler-to-C convert would almost always produce
smaller code than a C 'purist'. OK the code may not look as pretty,
but pretty code isn't a lot of use if it doesn't fit the chip!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\30@044628 by mike

flavicon
face
On Mon, 30 Oct 2000 21:24:29 +0200, you wrote:

>>From: Byron A Jeff <spamBeGonebyron@spam@spamspam_OUTCC.GATECH.EDU>
>
>>Actually I have a different take on it: C really isn't suitable for
>>embedded systems programming. It's a general purpose language applied to
>>the task.
>
>Afaik C is a systems programming language and was designed as such and for
>that purpose. They did not actually know what kind of (PDP) system it was
>for so they made some features up on the way. It cannot be an accident
>that 90% of the operating systems in common use are written in C or some
>dialect thereof. It is not pretty and it allows you to rummage in the
>gearbox at will. That's what makes it so different from other 'beautiful'
>languages which are less good for systems programming for various reasons.
>
>I think that the highly portable nature of C is due to the machine
>independent 'structured assembly language' concept they had to use to
>accomodate the wildly varying instruction sets of the PDP machines and
>other monsters they were using at the time.
..and of course the portability is a virtual non-issue for small
microcontrollers - maybe a marginal advantage in not having to
re-learn a new language  (apart from all the target- and compiler-
specific stuff...)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\30@072759 by Bob Ammerman

picon face
>>Of course you now insist that your students use -pedantic at all times,
>>right :-)

>Is there not some way of having a system wide default setting that they do
not realise exists to enforce it?? Gotta >play these students at their own
game  ;))

Simply tell them that they have to submit source code, and that _you_ are
going to compile it with --pedantic, and while we are at it, that you are
going to 'lint' it at maximum sensitivity.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\30@145407 by jamesnewton

face picon face
More than the syntax of the language, I feel that the major failing of
embedded programming languages are as follows:
A) Piss poor, inconsistent or no macro pre-processing
B) Lack of USEFULL access to the generated code and to the library of
routines that will be used to generate the code.
C) Lack of open source.
E) Lack of integration with the debugger.

What we really need is a really good macro pre-processor to BUILD the
language out of (99% of an assembler is just macro definitions with db's
inside, and a good macro language can make all the if, thens, switch, case,
do while, and whatevers you want) and a library manager that lets us keep
multiple versions of routines and finds the "best fit" by looking at bit
width, required accuracy, code space available, timing requirements and
other items that non-embedded languages don't usually care about. And it has
to be open source.

And another thing... it should make it very easy to feedback improvements...
For example: If you ask it to compile varA = functionA(functionB) and you
look at the result and see that some of functionB's exit code can be
combined with functionA's entry code, and you change it, a message
describing the optimization of functionA(functionB) should be sent to a
central site so that the next time someone asks for that specific
combination of functions, they at least get the option to select the
optimized version.

Ok, am I the only person that sees it this way?

---
James Newton (PICList Admin #3)
TakeThisOuTjamesnewtonspamspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\10\30@161025 by jamesnewton

face picon face
Err... yes, but forwards not backwards.

---
James Newton (PICList Admin #3)
jamesnewtonEraseMEspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\10\30@172451 by Bill Westfield

face picon face
   What we really need is a really good macro pre-processor to BUILD the
   language out of (99% of an assembler is just macro definitions with
   db's inside, and a good macro language can make all the if, thens,
   switch, case, do while, and whatevers you want)

Well, there are plenty of stand-alone macro "preprocessors" that are
probably suitably powerful and open source (m4, for instance?)  But...
lacking widespread standardization of the macros in use, this results
in HORRIBLY unreadable (and not very portable) code.  I knew a guy in
college that had succeeded in making the local assembler look like an
interesting cross between basic, fortran, and APL...  Yuck.


   and a library manager that lets us keep multiple versions of routines
   and finds the "best fit"

Like java's (and others?) feature that allows "add (char a, char b)"
to be different code from "add (short a, short b)" ?

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\30@180237 by jamesnewton

face picon face
I'm thinking of a "packaging" of something like M4 with a set of macros that
implements a basic assembler PLUS some nice structured programming
constructs like for next, if then, do while, repeat until, select case,
etc... then add something like the Java feature you mentioned that does find
the right version of function based on what it is being handed...

...The magic part of that is parameter matching... you either have to take
all the parameters as copies or pointers or something has to "mung" the
registers used by routineA over into those used by routineB. Of course if
routineB only gets used once, and its code refers to <regA> instead of using
a cblock or define and a register name, then the library code could replace
<regA> with the register that routineA returned its value in...

Nik and I and Jon Hylands have discussed this to death and ended up not
doing much with it, but I'm still interested in trying it.

---
James Newton (PICList Admin #3)
RemoveMEjamesnewtonEraseMEspamspam_OUTpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\10\31@044228 by Alan B. Pearce

face picon face
>Like java's (and others?) feature that allows "add (char a, char b)"
>to be different code from "add (short a, short b)" ?

This sounds a bit like the original 8086 assembler that Intel produced. The
manual published the list of macros used to assemble the mnemonics into machine
code. The mnemonics were set up so they could distinguish the type of arguments
used and assemble the correct code, despite many mnemonics having several
different widths of arguments.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.





'[OT]: Elegant way round C scoping problem..?'
2000\11\01@142628 by Peter L. Peres
picon face
>I'm thinking of a "packaging" of something like M4 with a set of macros
>that implements a basic assembler PLUS some nice structured programming
>constructs like for next, if then, do while, repeat until, select case,
>etc... then add something like the Java feature you mentioned that does
>find

I dunno if M4 is up to it alone, as M4 is single pass and any assembler
requires 2 passes, so you need a shell. Since you need a shell, you may
not need M4 since a shell like Bash is powerful enough to write an
assembler in. I am not joking. There are precedents ;-). In fact I think
that some people could write an assembler using the DOS batch language
only given the patience (shudder).

The Java feature you mentioned is in fact type sensitive scoping as in C++
and other languages (like Basic). You can implement it using M4 or
whatever, by mangling the function name internally with a simple (string)
hash of the function parameters types and the return type. F.ex.

int foo(char a, int b);

will be munged internally to:

ici_foo(a,b)

Of course when you do this in a proper programming language you don't do
it like this, you use a proper set of data structures instead.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use @spam@listservRemoveMEspamEraseMEmitvma.mit.edu?body=SET%20PICList%20DIGEST




More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...