• State Not Answered
  • Locked Locked
  • Replies 65 replies
  • Subscribers 22 subscribers
  • Views 5614 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C

Lou Rosinski

I was hoping to find on-line manuals that I could print and read on the john. So far no luck. But what I really need is how to declare variables in C.

For example, I have a sample code that has the statement:

unsigned char

and

unsigned long

What do these mean and do they limit the declaration to integers. What do i declare if I want a floating point?

Also, someone told me I cant do floating point with a Keil Compiler because of licensing issues (I got my copy from Silicon Labs and have just registered it). I will eventually need to do trig functions. What do i have to get (buy) to complete my project?

Parents
  • 0 in reply to Rab Gillatt

    If the C bots could get rid of "unsigned character", when they mean "byte",

    typedef unsigned char byte;

    allow base 2 in the source,

    There are some #define tricks to do something along those lines. Or write your own preprocessor.

    and get rid of most of the darned braces I would be happy to meet 1/2 way.

    #define { BLOCK_STARTS_HERE
#define } BLOCK_ENDS_HERE

    Then again, I don't think this is any better than using braces. ;)

    And you can probably write C code without using any more braces than required for enclosing functions in, I think. However, this would probably result in some of the most mindbogglingly convoluted C code that was ever written (since it would require heavy use of gotos, omitting most control structures, etc).

    Compound statements ("blocks") are a basic element of structured programming.

Reply
  • 0 in reply to Rab Gillatt

    If the C bots could get rid of "unsigned character", when they mean "byte",

    typedef unsigned char byte;

    allow base 2 in the source,

    There are some #define tricks to do something along those lines. Or write your own preprocessor.

    and get rid of most of the darned braces I would be happy to meet 1/2 way.

    #define { BLOCK_STARTS_HERE
#define } BLOCK_ENDS_HERE

    Then again, I don't think this is any better than using braces. ;)

    And you can probably write C code without using any more braces than required for enclosing functions in, I think. However, this would probably result in some of the most mindbogglingly convoluted C code that was ever written (since it would require heavy use of gotos, omitting most control structures, etc).

    Compound statements ("blocks") are a basic element of structured programming.

Children
  • 0 in reply to Christoph Franck

    The size difference between assembler and C can also come from calling a C RTL that drags in large blocks of library code. This quickly offsets the quota between C and assembler for smaller programs.

  • 0 in reply to ImPer Westermark

    The size difference between assembler and C can also come from calling a C RTL that drags in large blocks of library code. This quickly offsets the quota between C and assembler for smaller programs.

    Having a look at the list files should make it clear where the C program is burning those extra 3k.

  • 0 in reply to Christoph Franck

    First;
    Andy, thanks for the link to the nop info.

    Also guys, I take your point about #defining, C does have enough higher level functionality to make it very usable.
    I think my overall point is, should a high level language mean you have to remember dozens of tokens and their weird variants? More pertinent, writing effectively for embedded 8bit hardware really does call for a lot of bit twiddling. It is so easy when you can see the binary on the page rather than converting to and from hex on a handy jotter. Less room for error too. I want compact runtime output but I can't see any need for especially compact source code, quite the reverse really. The closer I can get to natural English the better.

    Sorry Lou, I'm being nostalgic. PLM was a family of languages designed by Intel for embedded work with their uCs and Ps. Based on IBM's PL/1 mainframe language and very popular in the 70's and 80's.
    The code output was phenomenally compact. I wrote 1000s of lines of assembler for the 80188 and 8051. When I started using PLM I was sceptical about efficiency but could rarely improve on the compiler with hand coding. Maybe I'm just a lousy assembly programmer and a grumpy old man.

    Good to see a vigorous forum here anyway. I'll shut up now and get back to work.

  • 0 in reply to Rab Gillatt

    en.wikipedia.org/.../M

    Holy cow, Rob, you're an old relic :-)

    I must admit I have never heard of PL/M before you mentioned it - I was not even born when it was conceived...

  • 0 in reply to Tamiryan Michael

    True, but many a fine tune played on an old fiddle. I was years away doing VHDL and just got back to the '51, using C this time round.

    "Old engineers never die they just get noisy and attenuated"

  • 0 in reply to Rab Gillatt

    PLM51 is quite nice. It adds structure similar to C, but limits the possible declarations a bit to make sure that you can't write processor-hostile constructs.

    No more than two months since last I had to look at a PLM51 program - some products just refuses to die :)

  • 0 in reply to ImPer Westermark

    I still have PLM51 and '86 compilers/linkers I have the compiler manuals but the linker manuals went south a long while ago. I would love to find copies of these again. Anyone?

    Regards

  • 0 in reply to Rab Gillatt

    I would love to find copies of these again.

    Yes, I worked in PLM51 as well. And, I have all of the original Intel manuals (in the silly printed semi-half-page format). If you're ever in Dallas, look me up.

    Jon

  • 0 in reply to Jon Ward

    Hi, the www is just amazing. But hey, look after them, its mostly nostalgia working but I might just call by one day. Regards :-)