Best tools for 8088 microcontroller?
Christopher Burian
I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
controller. It downloads a *.EXE program and stores it into EEPROM under
what MICRO/SYS calls the RUN.EXE system which contains a PC and DOS like
BIOS. My application has no file capability (no soft disk) and no display,
keyboard, etc. I'm limited to 128k of EEPROM and 128K of static RAM.
My previous 8088 experience is with MASM (v6 in v5 compatibility mode),
(an incomplete installation of) MS C 6.0, and QuickC 2.
I figured 'QuickC and QuickAssembler' would be ideal for getting code running
fast, but M$ discontinued it years ago because they claim Visual C++ is
"better."
What would be the best tools to get running fast? TurboAssembler + TurboC++?
MASM + VC++? I've never used the Borland tools, but I suppose it wouldn't
be hard to learn. Other suggestions?
I prefer to do interrupt and other low level stuff in assy and link it with
C just out of familiarity, but I realize that everything can be done in just
C (or just assy). Should I go with Visual C++, as the M$ sales guy suggested?
(To be fair, he also suggested checking used bookstores for QC&QA.)
If anybody wants to sell the QC&QA bundle, I'm looking to buy. Either version
(2.01 or 2.51) is fine with me. Or if anyone knows where to buy used or
obsolete software, let me know.
Thanks for any advice,
Chris
Pascal Dornier
Christopher Burian wrote:
>
> I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
> controller. It downloads a *.EXE program and stores it into EEPROM under
> what MICRO/SYS calls the RUN.EXE system which contains a PC and DOS like
> BIOS. My application has no file capability (no soft disk) and no display,
> keyboard, etc. I'm limited to 128k of EEPROM and 128K of static RAM.
>
> My previous 8088 experience is with MASM (v6 in v5 compatibility mode),
> (an incomplete installation of) MS C 6.0, and QuickC 2.
Try Borland Pascal / Turbo Pascal. It includes an excellent built-in
assembler, and supports much better modularity than C (my
condolescences to the folks in comp.lang.c).
It should be very painless, you won't have to mess around with
Make files, external assemblers, or linkers !
--------------------------------------------------------------------
Pascal Dornier pdor...@best.com http://www.best.com/~pdornier
Your Spec + PC Engines = Custom Embedded PC Hardware
--------------------------------------------------------------------
Thad Smith
In article <57hu5v$k...@vixen.cso.uiuc.edu>,
cbu...@ll.mit.edu (Christopher Burian) wrote:
>I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
>controller.
>What would be the best tools to get running fast? TurboAssembler + TurboC++?
>MASM + VC++? I've never used the Borland tools, but I suppose it wouldn't
>be hard to learn. Other suggestions?
I've used Borland's Turbo C (and asm) with the MicroSys boards with
good success. In fact, the reason that I choose the MicroSys was that
they had built-in Turbo Debugger remote module, which works great with
Turbo Debugger. It should work fine with TC++/BC++ and Turbo Debugger
(in remote mode). As I recall, TD doesn't come with TC++, so you
would need to buy it separately -- perhaps it comes with TASM. An
older copy of the Borland software may even be better than the current
Windows-oriented version.
If you use an 80188-based board, you can use the -1 (compile for 186)
option to generate slightly better code than default for 8086.
Thad
Ken Tindell
In article <57hu5v$k...@vixen.cso.uiuc.edu>
cbu...@ll.mit.edu (Christopher Burian) wrote:
> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
> fast, but M$ discontinued it years ago because they claim Visual C++ is
> "better."
You should use Ada 95. Ada 95 compilers generate really good quality
code (as good as C) for the 8088.
Kaz Kylheku
Really? So all Ada 95 compilers (assuming that one even exists) generate
better code than all C compilers for the 8088.
Okay. I will file this away somewhere for future reference.
Dave Feustel
Kaz Kylheku (k...@vision.crest.nt.com) wrote:
I recommend Snobol.
--
Dave Feustel http://feustel.mixi.net
219-483-1857 mailto:feu...@netcom.com
Ken Tindell
In article <57kua9$8...@bcrkh13.bnr.ca>
k...@vision.crest.nt.com (Kaz Kylheku) wrote:
> In article <b1c7cc$e1f2e.1de@marius>, Ken Tindell <k...@nrtt.demon.co.uk> wrote:
>>In article <57hu5v$k...@vixen.cso.uiuc.edu>
>>cbu...@ll.mit.edu (Christopher Burian) wrote:
>>> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
>>> fast, but M$ discontinued it years ago because they claim Visual C++ is
>>> "better."
>>
>>You should use Ada 95. Ada 95 compilers generate really good quality
>>code (as good as C) for the 8088.
>
> Really? So all Ada 95 compilers (assuming that one even exists) generate
> better code than all C compilers for the 8088.
>
> Okay. I will file this away somewhere for future reference.
I was being sarcastic. Check out the "Ada 95 for Automotive Systems" thread
on comp.realtime for the people who really believe the above..
Christopher Burian
In <b1c7cc$e1f2e.1de@marius> k...@nrtt.demon.co.uk (Ken Tindell) writes:
]In article <57hu5v$k...@vixen.cso.uiuc.edu>
]cbu...@ll.mit.edu (Christopher Burian) wrote:
]> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
]> fast, but M$ discontinued it years ago because they claim Visual C++ is
]> "better."
]You should use Ada 95. Ada 95 compilers generate really good quality
]code (as good as C) for the 8088.
Hand assembling generates really good quality code, too, but I can't find
a PC with toggle switches on the front. I'll stick with C for now, despite
how great Ada, Pascal and hand assembly are.
BTW, do they make an Ada compiler for 4-bit uC's, in case I need to design
a particularly robust toaster or kitchen timer?
Thanks,
Chris
Chris Hills
In article <57n5cn$g...@vixen.cso.uiuc.edu>, Christopher Burian
<cbu...@ll.mit.edu> writes
because more people use it. More people will be able to help, more
people will have which ever compiler system you choose and know it's
problems.
I know more people use windows than OS-2 but OS-2 is supposed to be
better than windows but if one developes on OS-2 the support will be a
lot less than on windows. The same is true of languages. Theoretically
best and best practical choice are not the same.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\ Chris Hills,Tamworth Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ B77 5PG England /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Christopher Burian
In <$QrFeQAq...@phaedsys.demon.co.uk> Chris Hills <ch...@phaedsys.demon.co.uk> writes:
]In article <57n5cn$g...@vixen.cso.uiuc.edu>, Christopher Burian
]<cbu...@ll.mit.edu> writes
]>In <b1c7cc$e1f2e.1de@marius> k...@nrtt.demon.co.uk (Ken Tindell) writes:
]>
]>]In article <57hu5v$k...@vixen.cso.uiuc.edu>
]>]cbu...@ll.mit.edu (Christopher Burian) wrote:
]>]> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
]>]> fast, but M$ discontinued it years ago because they claim Visual C++ is
]>]> "better."
]>
]>]You should use Ada 95. Ada 95 compilers generate really good quality
]>]code (as good as C) for the 8088.
]>
]>Hand assembling generates really good quality code, too, but I can't find
]>a PC with toggle switches on the front. I'll stick with C for now, despite
]>how great Ada, Pascal and hand assembly are.
]>
]>BTW, do they make an Ada compiler for 4-bit uC's, in case I need to design
]>a particularly robust toaster or kitchen timer?
]>
]>Thanks,
]>Chris
]>
]Go with C. Not because it is "better" than Ada, Mod2, forth et al but
]because more people use it. More people will be able to help, more
]people will have which ever compiler system you choose and know it's
]problems.
The Ada reference is a joke carried over from another newsgroup. I'm
going to use C.
]I know more people use windows than OS-2 but OS-2 is supposed to be
]better than windows but if one developes on OS-2 the support will be a
]lot less than on windows. The same is true of languages. Theoretically
]best and best practical choice are not the same.
The problem is that my "best practical" choice is impossible because the
garbage tools from Micro$oft and their "competitors" won't run on my
286 with 1MB of RAM. There is a conspiracy to unnecessarily obsolete
old, but perfectly operable hardware. That's why I'm looking for
"QuickC & QuickAssembler," or better, old TurboC + TurboAssembler +
TurboDebugger that will run on a 286 with limited RAM and hard disk space.
I imagine the switches that the "modern" tools contain to force 8086 code
are there because no one bothered to take them out and not because the
bungholes actually intend to compile to "obsolete" platforms.
Personally, I think the copyright laws should be changed to reflect a "use it
or lose it" policy. If an original vendor refuses to sell me an old version
of their supposedly "obsolete" software, it should be perfectly legal for
somebody else to package and sell it. Same goes for out of print books,
IMO.
Chris
Walter Banks
>
> Personally, I think the copyright laws should be changed to reflect a "use it
> or lose it" policy. If an original vendor refuses to sell me an old version
> of their supposedly "obsolete" software, it should be perfectly legal for
> somebody else to package and sell it. Same goes for out of print books,
> IMO.
This is a way off topic but as soon as the the tax laws change to allow
a publisher to keep a few old copies around so they can support the last
few customers they will likely do so. As it stands those last copies are
expensive, too expensive to keep. Same for software old code may be
inexpensive to buy but support is a killer. It is actually cheaper to give
current updates to the customer.
Walter Banks
Thad Smith
In article <57v26c$3...@vixen.cso.uiuc.edu>,
cbu...@ll.mit.edu (Christopher Burian) wrote:
>Personally, I think the copyright laws should be changed to reflect a "use it
>or lose it" policy. If an original vendor refuses to sell me an old version
>of their supposedly "obsolete" software, it should be perfectly legal for
>somebody else to package and sell it. Same goes for out of print books,
>IMO.
I think some vendors will let you make a copy of an old version if you
purchase a license (i.e., software package) for a current version.
Check with Borland.
Thad
Charles Ader
Christopher Burian (cbu...@ll.mit.edu) wrote:
> Personally, I think the copyright laws should be changed to reflect a "use it
> or lose it" policy. If an original vendor refuses to sell me an old version
> of their supposedly "obsolete" software, it should be perfectly legal for
> somebody else to package and sell it. Same goes for out of print books,
> IMO.
Chris,
This provision already exists in the copyright law (sort of).
Copyrights do expire it just take awhile something like 50 years
unless it's renewed. Just thing PC-DOS 1.0 will be in the public
domain some time in 2031. :)
Charles.
Christopher Burian
In <caderE1...@netcom.com> ca...@netcom.com (Charles Ader) writes:
]Chris,
There's a nice thought. But I don't care if the copyright expires over
time--I think it should be void immediately when previously available
material is no longer available. There are *soooo* many out of print
books that people want or would want if they knew they existed. If a
law like this actually passed, it would provide the arm-twisting necessary
to insure that all books are available from somewhere, forever. If the
original publisher thinks it would be unprofitable to do on-demand
publishing of old works, then they could either sell the rights, license
the rights, or donate them to the public domain (or have them donated
by simply refusing to re-publish). If I want "How to Build Your Own
Working Robot Pet," TAB Books could supply it if they were motivated to
by the threat of losing their rights to the book. If I want Turbo C 2.0,
Borland or a licensed contractor could provide it along with docs on CD,
if suitably motivated. In the end, it would be a win-win situation for
everyone. Publishers get the extra profit, customers get the products
they want.
Chris
Jeff Lait
In article <5826et$4...@vixen.cso.uiuc.edu>,
First of all, re: books. What about the poor author? If the
rights automatically get dumped to public domain, he's SOL re: royalties.
As for software, I can think of nothing worse. To keep all
n versions on the market one must keep them running. This is expensive.
One needs to maintain n versions as opposed to the current one.
And, the company cannot drop the rights to pd, as this will
undercut their market for their "real" version.
It would be a win for consumers, yes, but publishers get an extra
cost (no doubt forwarded to those consumers who foolishly demand the
upper edge, or if not, included in the price for the lesser version.
Are you willing to pay $500 for TC 2.0? Howbout $1000? for enough
money, Borland will likely sell it to you, at worst you need to buy
the company. Does your law place an upper limit on what price is
considered "Available"?), and if the work is dropped into pd, the
author gets screwed.
--
- Jeff Lait (SOL)
Dale M. Rickman
You know, there is a complete solution for embeddded development (x86
embedded compiler, linker, assembler), rtos, and gorgeous XRAY debugger
available as one integrated and SUPPORTED kit from Microtec, the only
vendor who supports the entire product line - debugger, compiler and
rtos for REAL MODE x86 development and SEGMENTED protected mode x86
development and FLAT protected mode x86 development.
www.mri.com
check it out.
yes, i am in sales
but this is so obviously a better solution !
AT LEAST GO LOOK !
THERESA
Jerry Coffin
In article <E1vH8...@undergrad.math.uwaterloo.ca>,
jml...@undergrad.math.uwaterloo.ca says...
[ ... ]
> First of all, re: books. What about the poor author? If the
> rights automatically get dumped to public domain, he's SOL re:
> royalties.
Quite true - republication of old books is relatively common.
Unfortunately, re-release of old software isn't...
> As for software, I can think of nothing worse. To keep all
> n versions on the market one must keep them running. This is
> expensive.
To put it mildly...
> One needs to maintain n versions as opposed to the current one.
> And, the company cannot drop the rights to pd, as this will
> undercut their market for their "real" version.
> It would be a win for consumers, yes, but publishers get an
> extra cost (no doubt forwarded to those consumers who foolishly
> demand the upper edge, or if not, included in the price for the
> lesser version.
One basic law of economics (that generally doesn't get mentioned in
economics classes, AFAIK) is that there virtually no such thing as a
rule or law that hurts the company and is a win for the consumer. The
reality is, that if you make things more expensive for the company,
that extra cost is _guaranteed_ to be passed along to the consumer.
In this case it would likely mean that the companies would simply
raise the prices on the older versions of the software, to the point
that nobody would consider buying them - the usual reason for wanting
older versions is to run on older machines. If the older version
costs more than the new version plus a new machine...
> Are you willing to pay $500 for TC 2.0? Howbout $1000? for enough
> money, Borland will likely sell it to you, at worst you need to buy
> the company. Does your law place an upper limit on what price is
> considered "Available"?), and if the work is dropped into pd, the
> author gets screwed.
In fact, right now one CAN buy older versions of most software, and at
reduced prices instead of higher prices - I don't have their number
handy at the moment, but there's a place named something like Surplus
Software that specializes in selling out of date versions of software.
--
Later,
Jerry.
gran...@decus.org.nz
In article <57hu5v$k...@vixen.cso.uiuc.edu>, cbu...@ll.mit.edu (Christopher Burian) writes:
> I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
> what MICRO/SYS calls the RUN.EXE system which contains a PC and DOS like
> BIOS. My application has no file capability (no soft disk) and no display,
> keyboard, etc. I'm limited to 128k of EEPROM and 128K of static RAM.
>
> My previous 8088 experience is with MASM (v6 in v5 compatibility mode),
> (an incomplete installation of) MS C 6.0, and QuickC 2.
>
> fast, but M$ discontinued it years ago because they claim Visual C++ is
> "better."
This is an increasing 'trend', and it is likely to cause significant support
problems, longer term. I know somwone looking for QuickBASIC, just to patch
a couple of fixes to some hitorical code that arrived from the UK, to be
given the same MS line.
Another point that will need watching is 8088 code generation, vs 286/386
code gens - how will you know on your Pentium if the newest Win95 toolset
and ASM libs is not sneaking a few of these into your 8088 system....
16 BIT C compilers, for 8088, may go theway of ISA bus VGA cards, and
9600 Baud Modems....
>
> What would be the best tools to get running fast? TurboAssembler + TurboC++?
> MASM + VC++? I've never used the Borland tools, but I suppose it wouldn't
> be hard to learn. Other suggestions?
>
> I prefer to do interrupt and other low level stuff in assy and link it with
> C just out of familiarity, but I realize that everything can be done in just
> C (or just assy). Should I go with Visual C++, as the M$ sales guy suggested?
> (To be fair, he also suggested checking used bookstores for QC&QA.)
I would suggest any of the following
- Older copies of MS C or Borland C
- Borland Pascal - very easy to use, and adequate Speed / Size
- Modula-2 - TopSpeed V1.17 - smaller and faster code than Pascal
- Pascal+, from Stony Brook - Borland 'cloned', but smaller code gen
- Modula-2, from Stony Brook - WIn95 Hosted, DOS16 is one target
- Drop the 8088, and use a C51 core ;-) at 128K the 51 should win...
>
> If anybody wants to sell the QC&QA bundle, I'm looking to buy. Either version
> (2.01 or 2.51) is fine with me. Or if anyone knows where to buy used or
> obsolete software, let me know.
>
> Thanks for any advice,
> Chris
>
>
regards - jim granville.
Christopher Burian
In <1996Dec5....@decus.org.nz> gran...@decus.org.nz writes:
]In article <57hu5v$k...@vixen.cso.uiuc.edu>, cbu...@ll.mit.edu (Christopher Burian) writes:
]> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
]> fast, but M$ discontinued it years ago because they claim Visual C++ is
]> "better."
]This is an increasing 'trend', and it is likely to cause significant support
]problems, longer term. I know somwone looking for QuickBASIC, just to patch
]a couple of fixes to some hitorical code that arrived from the UK, to be
]given the same MS line.
Microsoft is particularly annoying because they decline to make their
compilers work in "compatibility" mode with earlier versions. Their
knowledge base is full of notes describing what is and isn't compatible.
(At least the information is there! But it doesn't do a lot of good to
know that QuickBasic object modules can only be linked with C programs
compiled with v5.1 or earlier, if one can't buy v5.1.)
]I would suggest any of the following
]- Older copies of MS C or Borland C
Luckily I found some
]- Borland Pascal - very easy to use, and adequate Speed / Size
]- Modula-2 - TopSpeed V1.17 - smaller and faster code than Pascal
]- Pascal+, from Stony Brook - Borland 'cloned', but smaller code gen
]- Modula-2, from Stony Brook - WIn95 Hosted, DOS16 is one target
I need to use C.
]- Drop the 8088, and use a C51 core ;-) at 128K the 51 should win...
I need the 8088 because I have to send data over GPIB and I don't have the
time or the inclination to build my own talker/listener. Time is more
important than cost, since there are only going to be two of them, and we
need them quickly.
The genuine "heart" of my project *is* an 8751. All of the important stuff
is done there. The 8088 just accepts the raw data from the 8751, formats
it, and sends it off to the remote host computer. The design is such that
the 8751 and it's data-gathering peripherals can be on a PC/104, IPack,
VME or any other plug-in card. PC/104 happened to be picked because I have
lots of PC experience and because the host computer and other equipment
are PCs. If it was my call, the 8751 would be on an ISA plug-in card
inside the host computer. But everything's gotta be external.
Chris
Scott Nudds
(Christopher Burian) wrote:
: I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
: controller. It downloads a *.EXE program and stores it into EEPROM under
: what MICRO/SYS calls the RUN.EXE system which contains a PC and DOS like
: BIOS. My application has no file capability (no soft disk) and no display,
: keyboard, etc. I'm limited to 128k of EEPROM and 128K of static RAM.
If you use C, you are going to have to modify the startup code, as
well as the code that allocates memory. You may also need to replace
_matherr and avoid or replace all DOS dependent functions.
Some example functions that typically use DOS are abort, clearerr,
clock, ctime, dup, exit (all memory allocation), kbhit, localtime,
perror, (all forms of consol I/O), signal, etc.
--
<---->
Scott Nudds
(Christopher Burian) wrote:
: Hand assembling generates really good quality code, too, but I can't find
: a PC with toggle switches on the front. I'll stick with C for now, despite
: how great Ada, Pascal and hand assembly are.
Why would you want to use toggle switches when a keyboard will allow
you to enter exactly the same code more efficiently and with less chance
of error.
C pushers will say anything to defend their religion.
--
<---->
Christopher Burian
In <587ego$l...@james.freenet.hamilton.on.ca> af...@james.freenet.hamilton.on.ca (Scott Nudds) writes:
](Christopher Burian) wrote:
]: Hand assembling generates really good quality code, too, but I can't find
]: a PC with toggle switches on the front. I'll stick with C for now, despite
]: how great Ada, Pascal and hand assembly are.
] Why would you want to use toggle switches when a keyboard will allow
]you to enter exactly the same code more efficiently and with less chance
]of error.
I was suggesting that I would find Pascal about as pleasant to use as
an Altair 8008, or whatever those ROMless fossils were called.
] C pushers will say anything to defend their religion.
Ada and Pascal pushers are the fundies around here. I like assy best,
because I know exactly what is going on, and know that (usually) the only code
running is my code. I have yet to figure out why a 6k executable compiled
with C bloats into 70k of ram when it's run under dos. Who knows how big
an Ada program gets, or what the hell it's doing behind the programmer's
back once it's going? C is bad enough, these other languages are worse.
When every useful* machine instruction is encapsulated in an obese module
of range checking, stack checking, type checking, blah blah blah, I go
cross-eyed and feel woozy. Personally, I would defend C because it's the
most reasonable balance between ease of programming and intimacy with the
hardware, but a potent macro assembler would be better.
*useful == actually carrying out the intent of the programmer.
Fundie programmers couldn't care less what's actually going on inside
their machine. It's a black box, and for all they know or care, there
might be a Babbage Engine, a Turing Machine, or a bunch of little elves
in there. OTOH, all I care about is what is going on inside the machine.
Chris
Pascal Dornier
[comp.lang.c taken off newsgroup list]
Christopher Burian wrote:
> I was suggesting that I would find Pascal about as pleasant to use as
> an Altair 8008, or whatever those ROMless fossils were called.
ROFLMAO.
> Ada and Pascal pushers are the fundies around here. I like assy best,
> because I know exactly what is going on, and know that (usually) the only code
> running is my code. I have yet to figure out why a 6k executable compiled
> with C bloats into 70k of ram when it's run under dos. Who knows how big
> an Ada program gets, or what the hell it's doing behind the programmer's
> back once it's going? C is bad enough, these other languages are worse.
How do you know ? Have you tried ? The problem with C is the
printf procedure, which will require the linker to include a
shitload of code to support floating point etc, even if your
program doesn't use it.
> When every useful* machine instruction is encapsulated in an obese module
> of range checking, stack checking, type checking, blah blah blah, I go
> cross-eyed and feel woozy. Personally, I would defend C because it's the
> most reasonable balance between ease of programming and intimacy with the
> hardware, but a potent macro assembler would be better.
The pragma {$R-,I-,S-} will take care of those in Borland Pascal.
Type checking is performed at compile time, and does not increase code
size or execution time.
> *useful == actually carrying out the intent of the programmer.
A non-optimizing, not object oriented compiler will perform less
"magic" and is more likely to do what the programmer wants. This is
a tradeoff, of course.
> Fundie programmers couldn't care less what's actually going on inside
> their machine. It's a black box, and for all they know or care, there
> might be a Babbage Engine, a Turing Machine, or a bunch of little elves
> in there. OTOH, all I care about is what is going on inside the machine.
You can care about what is going on inside the machine, and still use
one of those "fundamentalist, quiche eater languages". What you are
overlooking are the code reliability and modularity advantages
afforded by properly designed programming languages.
patrick
There is a shareware compiler called micro c. This compiler compiles code
in small and tiny models only. It will produce .asm code for masm 5.1. it
comes with a good set of libraries ect.
I have tried it on simple code. it work O.K..
patrick wilder
Robert Krawitz
Ada and Pascal pushers are the fundies around here. I like assy
best, because I know exactly what is going on, and know that
(usually) the only code running is my code. I have yet to figure
out why a 6k executable compiled with C bloats into 70k of ram when
it's run under dos. Who knows how big an Ada program gets, or what
the hell it's doing behind the programmer's back once it's going?
C is bad enough, these other languages are worse. When every
useful* machine instruction is encapsulated in an obese module of
range checking, stack checking, type checking, blah blah blah, I go
cross-eyed and feel woozy. Personally, I would defend C because
it's the most reasonable balance between ease of programming and
intimacy with the hardware, but a potent macro assembler would be
better.
C (the language) doesn't do range checking or runtime type checking of
anything. This amount of growth is probably from the library (do you
use printf() anywhere?).
In any event, with larger programs and more data, the amount of growth
isn't linear -- there's generally a more or less fixed amount of
growth with the library.
--
Robert Krawitz <r...@tiac.net> http://www.tiac.net/users/rlk/
Member of the League for Programming Freedom -- mail l...@uunet.uu.net
Tall Clubs International -- http://www.tall.org/ or 1-800-521-2512
Jim Neil
>Ada and Pascal pushers are the fundies around here. I like assy best,
>because I know exactly what is going on, and know that (usually) the only code
>running is my code. I have yet to figure out why a 6k executable compiled
>with C bloats into 70k of ram when it's run under dos. Who knows how big
>an Ada program gets, or what the hell it's doing behind the programmer's
>back once it's going? C is bad enough, these other languages are worse.
>When every useful* machine instruction is encapsulated in an obese module
>of range checking, stack checking, type checking, blah blah blah, I go
>cross-eyed and feel woozy. Personally, I would defend C because it's the
>most reasonable balance between ease of programming and intimacy with the
>hardware, but a potent macro assembler would be better.
>
>*useful == actually carrying out the intent of the programmer.
>
>Fundie programmers couldn't care less what's actually going on inside
>their machine. It's a black box, and for all they know or care, there
>might be a Babbage Engine, a Turing Machine, or a bunch of little elves
>in there. OTOH, all I care about is what is going on inside the machine.
Chris-
Based on your statement:
Personally, I would defend C because it's the most reasonable
balance between ease of programming and intimacy with the
hardware, but a potent macro assembler would be better.
it is clear to me that you haven't seen or taken a serious look at
TERSE. TERSE gives the programmer FULL control over EVERYTHING
with the look-and-feel and ease-of-use of a HLL. If you really
care about what is going on "inside the machine", but would like
to be more productive and produce code that is easier to write/
read/maintain, please take a look at TERSE. You can get more
information about TERSE by visiting the TERSE Website at:
or you can eMail me and I'll send you some. ANYTHING you can
write in assembly, you can write in TERSE, without assembler's
primitive syntax, and you don't give up ANY of the power of your
assembler's Macros!
Jim Neil ___ ___/ ____/ ___ / ____/ ____/
Creator of The / / / / / /
TERSE Programming Language / ___/ ___/ ____ / ___/
ISBN: 0-9652660-0-1 / / / \ / /
jim-...@digital.net __/ ______/ __/ __\ ______/ ______/ TM
http://www.terse.com
Christopher Burian
In <58b523$b...@ddi2.digital.net> jim-...@digital.net (Jim Neil) writes:
]it is clear to me that you haven't seen or taken a serious look at
]TERSE. TERSE gives the programmer FULL control over EVERYTHING
]with the look-and-feel and ease-of-use of a HLL.
I thought TERSE was a task-switcher for the 8051. Is the computer industry
growing so fast that we're running out of names for things? :-) See:
http://scorpion.cowan.edu.au/science/terse/index.html
I saw the TERSE example code you posted, and it looked interesting. Thanks
for the reference.
Chris
Scott Nudds
Chris Hills wrote:
: Go with C. Not because it is "better" than Ada, Mod2, forth et al but
: because more people use it.
Lemming.
--
<---->
Sean 'Captain Napalm' Conner
So if we all starting using Assembly language and refulse to use C, we're
NOT lemmings, even though we're following you?
-spc ("We're all individuals! We all don't think alike!")
Bill Sturm
Scott Nudds wrote:
>
> (Christopher Burian) wrote:
> : I'm using a MICRO/SYS SBC 1188, which is a PC/104 bus PC-like embedded
> : controller. It downloads a *.EXE program and stores it into EEPROM under
> : what MICRO/SYS calls the RUN.EXE system which contains a PC and DOS like BIOS.
> If you use C, you are going to have to modify the startup code, as
> well as the code that allocates memory. You may also need to replace
> _matherr and avoid or replace all DOS dependent functions.
>
> Some example functions that typically use DOS are abort, clearerr,
> clock, ctime, dup, exit (all memory allocation), kbhit, localtime,
> perror, (all forms of consol I/O), signal, etc.
> Micro/Sys's RUN.EXE firmware addresses these issues...A DOS exe file
will execute just fine. It cannot perform file I/O however, which is
probably a good thing on it's intended environment.
Bill Sturm
Alicia Carla Longstreet
Christopher Burian wrote:
>
> In <1996Dec5....@decus.org.nz> gran...@decus.org.nz writes:
>
> ]In article <57hu5v$k...@vixen.cso.uiuc.edu>, cbu...@ll.mit.edu (Christopher Burian) writes:
> ]> I figured 'QuickC and QuickAssembler' would be ideal for getting code running
> ]> fast, but M$ discontinued it years ago because they claim Visual C++ is
> ]> "better."
> I need the 8088 because I have to send data over GPIB and I don't have the
> time or the inclination to build my own talker/listener. Time is more
> important than cost, since there are only going to be two of them, and we
> need them quickly.
>
> The genuine "heart" of my project *is* an 8751. All of the important stuff
> is done there. The 8088 just accepts the raw data from the 8751, formats
> it, and sends it off to the remote host computer. The design is such that
> the 8751 and it's data-gathering peripherals can be on a PC/104, IPack,
> VME or any other plug-in card. PC/104 happened to be picked because I have
> lots of PC experience and because the host computer and other equipment
> are PCs. If it was my call, the 8751 would be on an ISA plug-in card
> inside the host computer. But everything's gotta be external.
In reference to the above, Power-C from Mix Software ($19.95 plus $5.00
S&H) is ANSI compliant and compatible with Microsoft's QuickC (QuickC
code will compile with almost no changes), it is available only from the
publisher, (214)783-6001. If you call them ask about there symbolic
debugger and the source for the standard library.
To replace QuickAssembler you can download A86 assembler from several
places on the net (use Yahoo to search for A86, you will find it). A8g
is the BEST assembler for DOS ever. It is extremely fast and small (the
assembler A86.com is like 20K) comes with a debugger and some other neat
stuff. It was written by Eric Isaacson and will assembler MASM or Quick
Assembler code with ease, writing for the A86 is even easier.
Power-C, Power-CTrace, the source for the Standard library, and A86 will
cost a total of $104.90 (when you send Eric Isaacson the $50.00 he asks
for A86). Both products are fast, produce small executables, and are
inexpensive. Both are very easy to use. A86 defaults to producing .COM
files (no linking), Power-C can autolink with the /e switch, Power-C has
a built-in make facility.
Last, but not least, the manual that comes with Power-C is well worth
the price.
Alicia Carla Longstreet
Press any key to continue or any other key to quit
Richard Moore
Alicia Carla Longstreet wrote:
> In reference to the above, Power-C from Mix Software ($19.95 plus $5.00
> S&H) is ANSI compliant and compatible with Microsoft's QuickC (QuickC
> code will compile with almost no changes), it is available only from the
> publisher, (214)783-6001. If you call them ask about there symbolic
> debugger and the source for the standard library.
I bought a C compiler from MIX software years ago (when Lattice
was *the* standard for PC C-compilers and Turbo-C hadn't come out yet --
yikes!)and found that it was actually a p-code compiler and was deadly
slow. Is this still the case? If so I would stay away from it. If not,
glad to hear that they stopped selling a p-code compiler.
--
Richard Moore
Sr. Research Engineer
CMU National Robotics Engineering Consortium
(412)576-9022 (voice) (412)681-6961 (fax)
Gareth Baron
Nudds! You're so narrow minded. Why do people use C?
1) It's maintainable (not spagetti like if designed in a modular
professional fashion)
2) It's quicker time to market (that's the name of the game you know)
3) There is a lot of free resources around (GNU code etc)
4) You don't have to write everything from scratch
I'm not saying either of the languages are better (C Vs. Assembler).
They have to co-exist for products to be implemented efficiently. The
name of the game today is - 'Get it to market quickly'. You wouldn't get
your BIOS in your new PC very quicky otherwise, would you? That's FACT!
--
Gareth Baron.
Email: gar...@trsys.demon.co.uk
Scott Nudds
(Robert Krawitz) wrote:
: C (the language) doesn't do range checking or runtime type checking of
: anything.
Facilities for range checking should exist in C. Pointers should be
able to be assigned to objects with facilities for automatic bounds
runtime bounds checking.
--
<---->
Dik T. Winter
Facilities for range checking should exist in Assembler. Pointers should
be able to be assigned to objects with facitlities for automatic bounds
<sic> runtime bounds checking.
Rest assured Scott. There are loads of tools available for C that do just
what you want. Are there any for Assembler?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Colin W. Glenn
On Fri, 13 Dec 1996, Dik T. Winter wrote:
> > : C (the language) doesn't do range checking or runtime type checking of
>
> Rest assured Scott. There are loads of tools available for C that do just
> what you want. Are there any for Assembler?
BOUNDS
Michael Warner
>C (the language) doesn't do range checking or runtime type checking of
>anything. This amount of growth is probably from the library (do you
>use printf() anywhere?).
But C (the compiler) might insert code to check array index bounds,
detect stack overflow and so on. Nice to have during testing, but you
wouldn't want to ship it. IMHO the classic "hello world" starter uses
printf() rather than puts() so you learn the hardest library size lesson
first. After than, everything else is insignificant (except maybe sscanf()
and its relatives) :-)
My fuzzy recollection of Pascal is that all array index bounds have to be
given explicitly, and that going outside them is a language violation; if
this is the case any compiler which _didn't_ do range checking would be
remiss. I prefer the idea of the array operator as pointer offset,
myself :-)
My main recollection of Pascal is that the implementation I used (on a
VAX) was loaded with non-standard modifiers and tricks so that useful
code could actually be written. What a poncy little toy dog of a language.
How did I get onto this?
Scott Nudds
Alicia Carla Longstreet <ca...@ici.net> wrote:
: In reference to the above, Power-C from Mix Software ($19.95 plus $5.00
: S&H) is ANSI compliant and compatible with Microsoft's QuickC (QuickC
: code will compile with almost no changes), it is available only from the
: publisher, (214)783-6001. If you call them ask about there symbolic
: debugger and the source for the standard library.
But Kaz says its not a C compiler, that it's some kind of bastard
piece of garbage. Course Kaz says that about any C compiler that fails
to compile his code.
So much for C portability.
--
<---->
Scott Nudds
: >Chris Hills wrote:
: >: Go with C. Not because it is "better" than Ada, Mod2, forth et al but
: >: because more people use it.
Scott Nudds wrote:
: > Lemming.
(Sean 'Captain Napalm' Conner) wrote:
: So if we all starting using Assembly language and refulse to use C, we're
: NOT lemmings, even though we're following you?
A lemming is a lemming, no matter who he/she follows. Chris Hills has
told the world he is a lemming. His actions are driven by peer
pressure.
--
<---->
Scott Nudds
Gareth Baron wrote:
: Nudds! You're so narrow minded. Why do people use C?
: 1) It's maintainable (not spagetti like if designed in a modular
: professional fashion)
Assembler is easily maintainable, modular, and provides good
facilities for data hiding.
Gareth Baron wrote:
: 2) It's quicker time to market (that's the name of the game you know)
Programming in assembler can be faster than programming in C.
Gareth Baron wrote:
: 3) There is a lot of free resources around (GNU code etc)
This is true.
Gareth Baron wrote:
: 4) You don't have to write everything from scratch
Same as # 3. Having a library of assembler routines is essential.
Gareth Baron wrote:
: I'm not saying either of the languages are better (C Vs. Assembler).
: They have to co-exist for products to be implemented efficiently. The
: name of the game today is - 'Get it to market quickly'.
And as a result, get it to market running 2 or more times slower than
needed, thereby forcing your client to purchase a faster computer.
--
<---->
Will Rose
Scott Nudds (af...@james.freenet.hamilton.on.ca) wrote:
Well, I use Mix C to compile MSDOS programs without especial difficulty.
It seems pretty standard, and works fairly well - the programs are
generally small utilities written for MSDOS, OS/2 and Unix. C code is
pretty portable if you think what you are doing.
: --
: <---->
Yaron Koler
hi
I search for simple OS for Motorola MC68LC302
can I get any recommendation ?
Thank
Yaron Koler
ECI Telecom
Robert Lin
Yaron:
You can take a look on RTXC's real-time kernel. We use it for similar
chip MC68PM302. Call 713-561-9990 for more info.
regards
robert
Yaron Koler (Yaron...@ecitele.com) wrote:
: hi
lr...@superlink.net
Hi,
below, Michael Warner wrote:
Michael Warner wrote:
> But C (the compiler) might insert code to check array index bounds,
Excuse me, but I don't understand how a C compiler can always know what the array index
bounds are, since I don't believe they are always available at compile time, and also
perhaps not always available at runtime either.
I guess I can see how a compiler producing a special 'debug' version of an executable
could do this, in part, by creating a special area, where the bounds for an array are
available, or, by passing an unseen parameter to each funtion that has a pointer as an
argument.
But I can't see how you could do this for the general case. I would be interested to
know how this could be done. Or even if it could be done.
TIA.
LR.
Ernst Jan Plugge
On 15 Dec 1996 14:44:52 GMT, m...@ozemail.com.au (Michael Warner)
wrote:
>>C (the language) doesn't do range checking or runtime type checking of
>>anything. This amount of growth is probably from the library (do you
>>use printf() anywhere?).
>
>But C (the compiler) might insert code to check array index bounds,
>detect stack overflow and so on. Nice to have during testing, but you
>wouldn't want to ship it. IMHO the classic "hello world" starter uses
>printf() rather than puts() so you learn the hardest library size lesson
>first. After than, everything else is insignificant (except maybe sscanf()
>and its relatives) :-)
Oh, boy, that's indeed a lesson to learn... The library overhead can
be staggering. And the more complex the libraries are, the bigger the
overhead (like 400+ Kb for a Delphi 2.0 Hello world app). It can get
really ugly.
One criterium I use to see how good a C compiler is, is to see how
small it can make your basic Hello world app, both using printf() and
puts(). IIRC, I once persuaded Watcom C to create one using printf(),
in a DOS .COM file, that was less than 10 Kb.
Shared libraries are a Good Thing.
>My fuzzy recollection of Pascal is that all array index bounds have to be
>given explicitly, and that going outside them is a language violation; if
>this is the case any compiler which _didn't_ do range checking would be
>remiss. I prefer the idea of the array operator as pointer offset,
>myself :-)
The fact that going outside array bounds is a language violation
doesn't mean the runtime system has to check it. Most do, however, or
can with a compiler option. HP/UX Pascal even checks every single
calculation for overflow (including integer ones), but I don't like
the enormous speed penalty.
I prefer doing bounds checking myself. Mostly because I can do it
better. If I'm going to loop through an array element by element, I
only have to check the upper and lower indices. If they're OK, all of
them will be.
Ernst Jan - r...@dds.nl
------------------------------------------------------------------
When you took my freedom, you set me free
When you took my power, you strengthened me
That is where I want to be
Free to be powerless, with the power not to be free
James Youngman
In article <32bac98c...@news.noord.bart.nl>, r...@dds.nl says...
>One criterium I use to see how good a C compiler is, is to see how
>small it can make your basic Hello world app, both using printf() and
>puts(). IIRC, I once persuaded Watcom C to create one using printf(),
>in a DOS .COM file, that was less than 10 Kb.
>
>Shared libraries are a Good Thing.
FWIW the last time I did this under Unix, I got the size down to 4K (exactly
the size of a page). On that system evenb the shared library loader is a
shared library!
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.
James Youngman
In article <5912t4$7...@morse.satech.net.au>, m...@ozemail.com.au says...
>But C (the compiler) might insert code to check array index bounds,
>detect stack overflow and so on. Nice to have during testing, but you
>wouldn't want to ship it.
FWIW "checkergcc" does this.
>My fuzzy recollection of Pascal is that all array index bounds have to be
>given explicitly, and that going outside them is a language violation; if
ditto in C, actually.
>this is the case any compiler which _didn't_ do range checking would be
>remiss. I prefer the idea of the array operator as pointer offset,
>myself :-)
Alicia Carla Longstreet
James Youngman wrote:
> In article <32bac98c...@news.noord.bart.nl>, r...@dds.nl says...
>> One criterium I use to see how good a C compiler is, is to see how
>> small it can make your basic Hello world app, both using printf() and
>> puts(). IIRC, I once persuaded Watcom C to create one using printf(),
>> in a DOS .COM file, that was less than 10 Kb.
> >Shared libraries are a Good Thing.
>
> FWIW the last time I did this under Unix, I got the size down to 4K
> (exactly the size of a page). On that system even the shared library
> loader is a shared library!
How about:
12-20-96 10:31 94 hello.c
12-20-96 10:33 3,136 HELLO.EXE
12-20-96 10:33 196 HELLO.MIX
This is with printf() and Power C on a DOS Bosx under Windows 95 and
4DOS version 5.02.
or:
12-20-96 10:36 92 Hello2.c
12-20-96 10:36 3,744 HELLO2.EXE
12-20-96 10:36 196 HELLO2.MIX
This is with puts() and Power C...
Alicia Carla Longstreet
Violence is the last resort of the incompetent.
Let's shoot Scott Nudds.
Colin W. Glenn
On 20 Dec 1996, James Youngman wrote:
> In article <32bac98c...@news.noord.bart.nl>, r...@dds.nl says...
It would seem to me, that you should be able to get it under 2k.
Charles W. Hubbard
On Thu, 19 Dec 1996 23:24:28 GMT, r...@dds.nl (Ernst Jan Plugge) wrote:
>One criterium I use to see how good a C compiler is, is to see how
>small it can make your basic Hello world app, both using printf() and
>puts(). IIRC, I once persuaded Watcom C to create one using printf(),
>in a DOS .COM file, that was less than 10 Kb.
The Watcom C compiler (v 9.51) for the QNX operating system generates
about a 4k executable for your basic "Hello World" program using
printf() and no special tweaking or linking. I realize this isn't a
fair comparison since its a different OS but I thought it was
intersting. BTW, the C++ equivelent (using cout <<) was something
like 25k I think. yech.
C.
Robert Bonomi
In article <32bb19ca....@news.3-cities.com>,
For reference, folks, I use a DOS C environment that _without_
any tweaking, produces a 3.4k executable for "Hello World".. 2k
of that is 'printf' support.
Richard Steven Walz
In article <59l58d$j...@news.ece.nwu.edu>,
This is So stupid! Can't a compiler be found that KNOWS a task is so
simple that it only needs under 32 bytes?? I simply do NOT see why C
has to be so stupid!! It is SUPPOSED to be so "close to assembler and
yet high level", but I have yet to see it do either well!! The most
intriguing thing about C and C++ is ONLY how hard they seem to be for
students to LEARN to PROGRAM with them! And yet there are tiny BASICS
for teensy microcontrollers which are quite close to a one to one with
assembly!! If people are going to EXIST who know how to program the
MONSTROUS number of things this society and culture needing automated NEXT,
then we are going to have to ditch things LIKE C and C++ and offer some
language that is simple for users, besides the terrible simplicity of
PIC RISC-type instruction sets!! They are SIMPLE, yes, but it takes too
bloody long to do anything with such limited 1 register systems! Why C
can't do "Hello World" in under 32 bytes IN DOS is absurd!! What IS printf()
support if it doesn't support the SIMPLEST possible job of the function!!
And WHY, for gawd's sake would he need 1.4k above for mere FLOW control
of a program with NO APPARENT FLOW!!!?? It SHOULD be embarrassing!!
How much would need to be added to a compiler to make it do such simple
straightforward DUMB things the easiest way when NOT calling a routine
for something major!!?? Why can it NOT distinguish the need for the
major handler routine to be present versus the dumb short form in the
compile!! Pitiful, just pitiful!! Do we have to look for a compiled
"Forth-like" thing (except that doesn't metacompile all progs into
itself) for such service of simple tasks intelligently?? As it is now,
it's nuts! NOBODY fucking knows what they are doing, and I can't find
many who can agree on what is even going ON in C and C++ programs,
even simple ones!! Recent graduates in CS make one cringe!! Ideas??
-Steve
--
-Steve Walz rst...@armory.com http://www.armory.com/~rstevew/
-Lots of New FTP Electronics Stuff!! 700 Files/40 Dirs (Full Mirror ==> *)
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com:/pub/user/rstevew *
Europe:(Italy) ftp://ftp.cised.unina.it:/pub/electronics/ftp.armory.com *
Oz: (Australia) ftp://gold.apana.org.au:/pub/electronics/ftp.armory.com *
(U.Cinci) ftp://ieee.cas.uc.edu:/pub/electronics/mirrors/ftp.armory.com *
James Youngman
In article <59m6gb$q...@news.scruz.net>, rst...@armory.com says...
>>For reference, folks, I use a DOS C environment that _without_
>>any tweaking, produces a 3.4k executable for "Hello World".. 2k
>>of that is 'printf' support.
>------------------------------
>This is So stupid! Can't a compiler be found that KNOWS a task is so
>simple that it only needs under 32 bytes?? I simply do NOT see why C
>has to be so stupid!!
pintf() does a lot of stuff. It's _bound_ to be a big function.
In this case, using printf() to print "Hello, world" is like using a
sledgehammer to crack a walnut.
However, printf() has its place. It's very useful, even though it takes up
several thousand bytes.
>It is SUPPOSED to be so "close to assembler and
>yet high level", but I have yet to see it do either well!!
It's a matter of viewpoint and expectation.
>The most
>intriguing thing about C and C++ is ONLY how hard they seem to be for
>students to LEARN to PROGRAM with them! And yet there are tiny BASICS
>for teensy microcontrollers which are quite close to a one to one with
>assembly!! If people are going to EXIST who know how to program the
>MONSTROUS number of things this society and culture needing automated NEXT,
>then we are going to have to ditch things LIKE C and C++ and offer some
>language that is simple for users, besides the terrible simplicity of
>PIC RISC-type instruction sets!! They are SIMPLE, yes, but it takes too
>bloody long to do anything with such limited 1 register systems! Why C
>can't do "Hello World" in under 32 bytes IN DOS is absurd!!
Please don't use zippy.el; it makes your posings hard to read :-)
>What IS printf()
>support if it doesn't support the SIMPLEST possible job of the function!!
It does. It's just overkill. It does "support" the simplest task. Did you
expect the compiler to use some "restricted" form of printf() if it sees you
aren't using all the features of the function?
>And WHY, for gawd's sake would he need 1.4k above for mere FLOW control
>of a program with NO APPARENT FLOW!!!?? It SHOULD be embarrassing!!
>How much would need to be added to a compiler to make it do such simple
>straightforward DUMB things the easiest way when NOT calling a routine
>for something major!!?? Why can it NOT distinguish the need for the
>major handler routine to be present versus the dumb short form in the
>compile!!
That is the job of the programmer. Calm down.
>Pitiful, just pitiful!! Do we have to look for a compiled
>"Forth-like" thing (except that doesn't metacompile all progs into
>itself) for such service of simple tasks intelligently?? As it is now,
>it's nuts! NOBODY fucking knows what they are doing, and I can't find
>many who can agree on what is even going ON in C and C++ programs,
>even simple ones!!
Sit down....breathe deeply.
Tim Behrendsen
Richard Steven Walz <rst...@armory.com> wrote in article <59m6gb$q...@news.scruz.net>...
> In article <59l58d$j...@news.ece.nwu.edu>,
> Robert Bonomi <bon...@ece.nwu.edu> wrote:
> >In article <32bb19ca....@news.3-cities.com>,
> >Charles W. Hubbard <chub...@oneworld.owt.com> wrote:
> >>On Thu, 19 Dec 1996 23:24:28 GMT, r...@dds.nl (Ernst Jan Plugge) wrote:
> >>
> >>>One criterium I use to see how good a C compiler is, is to see how
> >>>small it can make your basic Hello world app, both using printf() and
> >>>puts(). IIRC, I once persuaded Watcom C to create one using printf(),
> >>>in a DOS .COM file, that was less than 10 Kb.
> >>
> >>The Watcom C compiler (v 9.51) for the QNX operating system generates
> >>about a 4k executable for your basic "Hello World" program using
> >>printf() and no special tweaking or linking. I realize this isn't a
> >>fair comparison since its a different OS but I thought it was
> >>intersting. BTW, the C++ equivelent (using cout <<) was something
> >>like 25k I think. yech.
> >>
> >
> >any tweaking, produces a 3.4k executable for "Hello World".. 2k
> >of that is 'printf' support.
> ------------------------------
> This is So stupid! Can't a compiler be found that KNOWS a task is so
> simple that it only needs under 32 bytes?? I simply do NOT see why C
> can't do "Hello World" in under 32 bytes IN DOS is absurd!! What IS printf()
> support if it doesn't support the SIMPLEST possible job of the function!!
Why do I care if a useless program like "Hello World" takes the minimum
number of bytes? The fact is, 'printf' is capable of a lot more than
just displaying a text string. This cost is negligable as a percentage
of a real program.
> And WHY, for gawd's sake would he need 1.4k above for mere FLOW control
> of a program with NO APPARENT FLOW!!!?? It SHOULD be embarrassing!!
Who cares? If you want embarrasing, look at multi-megabyte programs.
That's where you should place your ranting, not in relatively small
library routines.
> How much would need to be added to a compiler to make it do such simple
> straightforward DUMB things the easiest way when NOT calling a routine
> for something major!!??
Perhaps not much, but again, how cares? The C standard libraries a
program uses are seldom the cause of modern program bloat. I am more
concerned with vendor libraries, particularly GUI libraries. Fortunately
shared libraries seem to be helping that situation, to some degree (except
many "modern" Unix systems *still* insist on linking the whole X11/Motif
library into every application).
Still, shared libraries just encourage the bad situation, where a
lazy programmer just says, "so what if I replicate the same code 10
times. It's all in a shared library."
And if I hear one more time, "Heck, with virtual memory, it will just
get swapped out", that unlucky person will get a gun to the head.
> Why can it NOT distinguish the need for the
> major handler routine to be present versus the dumb short form in the
> compile!! Pitiful, just pitiful!! Do we have to look for a compiled
> "Forth-like" thing (except that doesn't metacompile all progs into
> itself) for such service of simple tasks intelligently??
See above.
> As it is now,
> it's nuts! NOBODY fucking knows what they are doing, and I can't find
> many who can agree on what is even going ON in C and C++ programs,
Now, here's where I agree. I think it's pathetic that we have
so much code that is obviously poorly designed. I think the problem
is at the application level, however. I think your rant is misplaced
to put it on the linker/compiler.
> even simple ones!! Recent graduates in CS make one cringe!! Ideas??
They make me cringe, too. Thinking skills unfortunately are not
taught very well in modern C.S. They are too concerned with teaching
abstractions, and not enough teaching implementation and execution.
Unfortunately, there seems to be a rule that the more abstract
something is, the less efficient it gets. And C.S. is currently
devoted to more and more abstraction.
--
==========================================================================
| Tim Behrendsen | t...@a-sis.com |
| "All things come to those who work." | http://www.cerfnet.com/~timb |
|------------------------------------------------------------------------|
| Announcement: My C expression evaluator is available on my web site. |
| Its primary claim to fame is that it's very compact and extensible, |
| and supports C precedence, associativity, ternary operator, etc. |
==========================================================================
Colin W. Glenn
reply = apply(&prune[], chop[]);
On 23 Dec 1996, James Youngman wrote:
> In article <59m6gb$q...@news.scruz.net>, rst...@armory.com says...
> It's a matter of viewpoint and expectation.
He does, doesn't he.
#include <stdio.h>
main()
{
char out[] = "Hello World!";
for (int index = 0; out[index] != '\0'; index++) putchr(out[index]);
}
I'm just learning, so the question is, did I get it right?
Dan Haynes
Colin W. Glenn <cw...@gnofn.org> wrote in article
<Pine.GSO.3.95.96122...@sparkie.gnofn.org>...
Well... almost... :-)
#include <stdio.h>
void main( void ) <---- only real old, real hacky unix types who
*like* using cryptic debuggers don't use prototypes! :-)
{
register size_t index ;
static const char out[] = "Hello World!";
for ( index = 0; out[index] != '\0'; index++)
{
putchar(out[index]);
}
}
Making the string 'static const' will cause most compilers (all of the
ones worth spending money on anyway) to store the string in the text
segment. If you simply create an automatic array as in the original, a copy
of the string will be stored in the text segment and then copied onto the
stack at runtime. Many compilers optimize this copy using multiple moves,
and it can add significantly to the size of your code.
Being explicit about 'register' (in combination with the 'static const')
should allow the compiler to leave out the enter/leave or link/unlk
instructions needed to create a stack frame. We shouldn't *have* to say
'register' in this day and age, but there are some expensive compilers out
there that are helpless without out... :-\
The other trick, though not a lot of help in this particular case, is to
use unsigned numbers where the value can't logically be signed. This helps
a great deal on some processors, such as the 68K where a signed number
often generates separate checks for greater than and for zero.
One other potential optimization - if you must make multiple references to
'putchar', then put it into a separate function of your own, such as
void PutChar( int ch )
{
putchar( ch ) ;
}
Since in many implementations, putchar() is a macro, referencing it
multiple times can/will cause code bloat.
Of course, one could always just call 'puts()' instead of coding their
own... :-)
Sorry, I couldn't resist - I've been doin' this stuff for a few years now
and I get a giggle out of pointing out when it's a programmer defect, not a
language defect - no matter how hard the assembly language only types want
it to be! :-)
Dan Haynes
Scott Nudds
(Will Rose) wrote:
: Well, I use Mix C to compile MSDOS programs without especial difficulty.
Mix C is the worst C compiler I have seen. As a learning tool, I
would recommend it highly on the basis of cost.
Have you looked at the code it produces? I have.
--
<---->
Thad Smith
In article <01bbf2dc$19bfd5b0$7c8280d0@impasse>,
"Dan Haynes" <nos...@bitbucket.net> wrote:
>
>Colin W. Glenn <cw...@gnofn.org> wrote in article
><Pine.GSO.3.95.96122...@sparkie.gnofn.org>...
>> #include <stdio.h>
>> main()
>> {
>> char out[] = "Hello World!";
>> for (int index = 0; out[index] != '\0'; index++) putchr(out[index]);
>> }
>>
>> I'm just learning, so the question is, did I get it right?
>>
>
>Well... almost... :-)
Colin's program may be correct for C++, but in C the int declaration
must precede the start of the first executable statement (for).
Otherwise it should execute properly.
>#include <stdio.h>
>
>void main( void ) <---- only real old, real hacky unix types who
>*like* using cryptic debuggers don't use prototypes! :-)
A nit here. Since this is the definition of a function, it is not a
prototype, and adding void in the argument list does nothing.
While I do encourage the use of prototypes, there really is no
point in a prototype for main since no user code (normally) calls
it.
There are many programmers that complain that main should never be
written with a void return value, but in the case of embedded systems,
a return value may simply not be used. The C Standard even recognizes
this for freestanding implementations.
>{
>register size_t index ;
size_t is defined in <stddef.h>. It must be included.
>static const char out[] = "Hello World!";
>
> for ( index = 0; out[index] != '\0'; index++)
> {
> putchar(out[index]);
> }
>}
>
>Making the string 'static const' will cause most compilers (all of the
>ones worth spending money on anyway) to store the string in the text
>segment. If you simply create an automatic array as in the original, a copy
>of the string will be stored in the text segment and then copied onto the
>stack at runtime. Many compilers optimize this copy using multiple moves,
>and it can add significantly to the size of your code.
Good points.
>Being explicit about 'register' (in combination with the 'static const')
>should allow the compiler to leave out the enter/leave or link/unlk
>instructions needed to create a stack frame. We shouldn't *have* to say
>'register' in this day and age, but there are some expensive compilers out
>there that are helpless without out... :-\
I am seeing the opposite now: compilers that ignore register
declarations. There have been times that I want particular variables
in a register for optimization (I study the generated code and know
what I am doing), but the compiler simply ignores the register
declaration. The best implementation would be one that optimizes
without the declaration, but respects users' register declarations, if
possible, then optimizes the other variables within the constraints of
the variables assigned to registers.
What should happen if the user makes poor choices for register? The
compiler should simply follow the choices and generate the
correspondingly poorly optimized code. If no such declarations are
made, the compiler is free to optimize. Modern compilers that ignore
register declarations are not following the C precept of "trust the
programmer".
>The other trick, though not a lot of help in this particular case, is to
>use unsigned numbers where the value can't logically be signed. This helps
>a great deal on some processors, such as the 68K where a signed number
>often generates separate checks for greater than and for zero.
Good point. It helps on 8-bit processors, too.
>One other potential optimization - if you must make multiple references to
>'putchar', then put it into a separate function of your own, such as
>
>void PutChar( int ch )
>{
> putchar( ch ) ;
>}
>
>Since in many implementations, putchar() is a macro, referencing it
>multiple times can/will cause code bloat.
This leads to a useful technique: know the compiler and get familiar
with generated code. Know the tradeoffs between code space and
execution time.
Although putchar is, as Dan noted, typically implemented as a macro,
it can be bypassed in favor of the library routine by surrounding the
name in parentheses:
(putchar) (out[index]);
If the implementation doesn't have a separate library implementation,
it isn't conforming to Standard C.
Thad
Colin W. Glenn
On 26 Dec 1996, Dan Haynes wrote:
> > Colin Glenn said:
> > I'm just learning, so the question is, did I get it right?
> >
Yeah, I noticed that after I ^X'd the message outta pine.
> void main( void ) <---- only real old, real hacky unix types who
I always thought that you didn't need to use prototyping for main(), just
for your functions as a form of syntax checking.
> One other potential optimization - if you must make multiple references to
> 'putchar', then put it into a separate function of your own, such as
>
> void PutChar( int ch ) { putchar( ch ); }
> Since in many implementations, putchar() is a macro, referencing it
> multiple times can/will cause code bloat.
And probably the only way to find out is by looking at the source.
> Of course, one could always just call 'puts()' instead of coding their
> own... :-)
> Sorry, I couldn't resist - I've been doin' this stuff for a few years now
> and I get a giggle out of pointing out when it's a programmer defect, not a
> language defect - no matter how hard the assembly language only types want
> it to be! :-)
Hey, I resemble that remark, :). But really, one of the primary reasons
that I'm learning C is because it provides a means for a die-hard
preformance buff to tinker with the inner workings of the finished
program, but as the same time providing a easy to use means of handling
the large routines one would normally code by hand.
Colin W. Glenn
On 26 Dec 1996, Thad Smith wrote:
> "Dan Haynes" <nos...@bitbucket.net> wrote:
> >Colin W. Glenn <cw...@gnofn.org> wrote in article
> must precede the start of the first executable statement (for).
> Otherwise it should execute properly.
Never thought about that, most of the lessons I've read on C have used
this implementation as part of a lesson program.
> If the implementation doesn't have a separate library implementation,
> it isn't conforming to Standard C.
How would one go about determining if the library conforms to C?
Personally I've been trying to find a library tool on the net which would
allow me to extract/update the library module so I could see exactly what
was implemented in it.
Will Rose
Scott Nudds (af...@james.freenet.hamilton.on.ca) wrote:
No, I just use it because it is small, cheap, simple and ANSI.
For the stuff I use it for, good code quality isn't really important.
Ben Sauvin
Scott Nudds wrote:
>
> (Will Rose) wrote:
> : Well, I use Mix C to compile MSDOS programs without especial difficulty.
>
> Mix C is the worst C compiler I have seen. As a learning tool, I
> would recommend it highly on the basis of cost.
>
> Have you looked at the code it produces? I have.
>
If THAT is the basis on which you found your hatred of the C
programming language, it's small wonder!
As you say, it's a cheap teacher.
--
Benoit A Sauvin
Anti-spam device: underscore.
Opinions and misstatements are my own.
Thad Smith
In article <Pine.GSO.3.95.96122...@sparkie.gnofn.org>,
"Colin W. Glenn" <cw...@gnofn.org> wrote:
>On 26 Dec 1996, Thad Smith wrote:
>> "Dan Haynes" <nos...@bitbucket.net> wrote:
>> >Colin W. Glenn <cw...@gnofn.org> wrote in article
>> >> for (int index = 0; out[index] != '\0'; index++) putchr(out[index]);
>> Colin's program may be correct for C++, but in C the int declaration
>> must precede the start of the first executable statement (for).
>> Otherwise it should execute properly.
>
>Never thought about that, most of the lessons I've read on C have used
>this implementation as part of a lesson program.
There are many people that blur the distinction between C and C++
because they are so similar or because they use only C++ and have
never needed to know the distinction.
>> If the implementation doesn't have a separate library implementation,
>> it isn't conforming to Standard C.
>
>How would one go about determining if the library conforms to C?
That's a very difficult thing to do rigorously. There are commercial
products designed specifically to test conformance, but they are
expensive and even they are not completely thorough. In general, the
embedded cross compilers tend to have less complete library
implementations that hosted compilers.
As far as the particular item I mentioned, i.e., putchar implemented
as a library function (as well as a possible macro), write a simple
test program invoking putchar (with the parentheses to inhibit macro
use) and link it. If it links without listing putchar as an undefined
symbol, it's in there.
In general, if I want to know what a particular implementation does or
has or supports, I write a test program. I know, for example, what
code my compiler might generate for switch statements, because I have
tried different cases.
>Personally I've been trying to find a library tool on the net which would
>allow me to extract/update the library module so I could see exactly what
>was implemented in it.
The first indication of what is in the library is the documentation.
It is not always accurate, though. Here's a test of the completeness
of the documentation: does it list the offsetof macro that must be
included in <stddef.h>? Many implementations include the macro in the
header, but don't mention it in the documentation.
The next source for a list of library functions are the collective
header files. They are usually accurate, but they won't list routines
which are intended to be called only by other library routines or
implicitly by the compiler, e.g., division of long ints on platforms
not having a native long divide.
Thad
Richard Steven Walz
In article <59uno8$o...@james.freenet.hamilton.on.ca>,
Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
>(Will Rose) wrote:
>: Well, I use Mix C to compile MSDOS programs without especial difficulty.
>
> Mix C is the worst C compiler I have seen. As a learning tool, I
>would recommend it highly on the basis of cost.
>
> Have you looked at the code it produces? I have.
>
><---->
-----------------------------------------------
It's a real horror show, alright, in that it generates a 40KB "Hello
World" or such. Almost as though it's a simulator written as a virtual
machine. If anybody wants my copy, they can have it for my cost to
ship it. $10 in the USA, a bit more elsewhere. I used it for one or
two days, and then found BDS-C !!
Will Rose
Richard Steven Walz (rst...@armory.com) wrote:
: In article <59uno8$o...@james.freenet.hamilton.on.ca>,
: Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
: >(Will Rose) wrote:
: >: Well, I use Mix C to compile MSDOS programs without especial difficulty.
: >
: > Mix C is the worst C compiler I have seen. As a learning tool, I
: >would recommend it highly on the basis of cost.
: >
: > Have you looked at the code it produces? I have.
: >
: >--
: ><---->
: -----------------------------------------------
: It's a real horror show, alright, in that it generates a 40KB "Hello
: World" or such. Almost as though it's a simulator written as a virtual
: machine. If anybody wants my copy, they can have it for my cost to
: ship it. $10 in the USA, a bit more elsewhere. I used it for one or
: two days, and then found BDS-C !!
Some confusion here - the Mix C I use generates a 3024 byte "Hello, world".
And I thought BDS C was CP/M only? Certainly its non-standard libraries
were a pain, tho' for CP/M-only stuff it was very nice.
Lawrence Kirby
In article <01bbf2dc$19bfd5b0$7c8280d0@impasse>
dha...@avicom.net "Dan Haynes" writes:
>
>Colin W. Glenn <cw...@gnofn.org> wrote in article
><Pine.GSO.3.95.96122...@sparkie.gnofn.org>...
>> reply = apply(&prune[], chop[]);
>> On 23 Dec 1996, James Youngman wrote:
>> > In article <59m6gb$q...@news.scruz.net>, rst...@armory.com says...
>> > >>any tweaking, produces a 3.4k executable for "Hello World".. 2k
>> > >This is So stupid! Can't a compiler be found that KNOWS a task is so
>> > In this case, using printf() to print "Hello, world" is like using a
>> > >yet high level", but I have yet to see it do either well!!
>> > It's a matter of viewpoint and expectation.
>> > That is the job of the programmer. Calm down.
>>
>> He does, doesn't he.
>> #include <stdio.h>
>> main()
>> {
>> char out[] = "Hello World!";
>> for (int index = 0; out[index] != '\0'; index++) putchr(out[index]);
>> }
>>
>> I'm just learning, so the question is, did I get it right?
>>
>
>Well... almost... :-)
>
>#include <stdio.h>
>
>void main( void ) <---- only real old, real hacky unix types who
>*like* using cryptic debuggers don't use prototypes! :-)
This is simply incorrect since in C main() returns int.
>{
>register size_t index ;
It is good to know about size_t but you might as well use just int in this
case since we know that the range of values will fit in an int and it is
more likely to correspond to an efficient type for the platform.
>static const char out[] = "Hello World!";
>
> for ( index = 0; out[index] != '\0'; index++)
> {
> putchar(out[index]);
> }
>}
>
>Making the string 'static const' will cause most compilers (all of the
>ones worth spending money on anyway) to store the string in the text
>segment. If you simply create an automatic array as in the original, a copy
>of the string will be stored in the text segment and then copied onto the
>stack at runtime. Many compilers optimize this copy using multiple moves,
>and it can add significantly to the size of your code.
Fair comment.
>Being explicit about 'register' (in combination with the 'static const')
>should allow the compiler to leave out the enter/leave or link/unlk
>instructions needed to create a stack frame. We shouldn't *have* to say
>'register' in this day and age, but there are some expensive compilers out
>there that are helpless without out... :-\
Really? I'd be interested in an example. I gave up using register about 5
years ago because it didn't help.
>The other trick, though not a lot of help in this particular case, is to
>use unsigned numbers where the value can't logically be signed. This helps
>a great deal on some processors, such as the 68K where a signed number
>often generates separate checks for greater than and for zero.
Doesn't the 68K have condition tests to support both signed and unsigned
operations?
>One other potential optimization - if you must make multiple references to
>'putchar', then put it into a separate function of your own, such as
>
>void PutChar( int ch )
>{
> putchar( ch ) ;
>}
>
>Since in many implementations, putchar() is a macro, referencing it
>multiple times can/will cause code bloat.
Well, the idea is efficiency in avoiding a lot of function calls. I doubt
whether there is much code that uses putchar/putc/getchar/getc enough to
cause significant code bloat. Anyway if you don't want the macro version
simply put:
#undef putchar
after including stdio.h. Your code will then call the putchar function (which
is guaranteed by the standard to exist).
>Of course, one could always just call 'puts()' instead of coding their
>own... :-)
Well, the original doesn't output a new-line as puts() does, however the
new-line may be considered as an improvement.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
>>#include <stdio.h>
>>
>>void main( void ) <---- only real old, real hacky unix types who
>>*like* using cryptic debuggers don't use prototypes! :-)
>
>A nit here. Since this is the definition of a function, it is not a
>prototype,
It *is* a prototype. Prototype form was introduced in ANSI C and is the
form that defines types in the parameter list. The prototype form when there
are no parameters is a parameter list of just void as above.
>and adding void in the argument list does nothing.
The non-prototype form is obsolescent so the prototype form is more
future-proof.
>While I do encourage the use of prototypes, there really is no
>point in a prototype for main since no user code (normally) calls
>it.
You're saying "prototype" when you mean simply "declaration". Function
definitions (i.e. including a function body) can be prototyped.
>There are many programmers that complain that main should never be
>written with a void return value, but in the case of embedded systems,
>a return value may simply not be used.
Which doesn't make any difference. If you use the wrong return type main()
may not even be called successfully, e.g. when function that return int
have a different calling sequence to functions returning void. Even when
the return value isn't used it is wrong to define main as returning void.
> The C Standard even recognizes
>this for freestanding implementations.
C doesn't define main *at all* for freestanding implementations.
...
>I am seeing the opposite now: compilers that ignore register
>declarations. There have been times that I want particular variables
>in a register for optimization (I study the generated code and know
>what I am doing), but the compiler simply ignores the register
>declaration. The best implementation would be one that optimizes
>without the declaration, but respects users' register declarations, if
>possible, then optimizes the other variables within the constraints of
>the variables assigned to registers.
Maybe the compiler could give a bias towards variables declared register
>What should happen if the user makes poor choices for register? The
>compiler should simply follow the choices and generate the
>correspondingly poorly optimized code.
The problem is that C code can be compiled and run on many different
platforms. The programmer could provide hints as to what variables are
most used algorithmically speaking but it shopuld be up to the compiler
to allocate registers as appropriate for the archetecture.
>If no such declarations are
>made, the compiler is free to optimize. Modern compilers that ignore
>register declarations are not following the C precept of "trust the
>programmer".
The problem is that register is far too blunk an instrument for the purpose
you are intending. Modern compilers can put different variables into
registers at different times which is much more flexible than the register
keyword could ever hope to be.
>>The other trick, though not a lot of help in this particular case, is to
>>use unsigned numbers where the value can't logically be signed. This helps
>>a great deal on some processors, such as the 68K where a signed number
>>often generates separate checks for greater than and for zero.
>
>Good point. It helps on 8-bit processors, too.
8 bit targets are rather rare and specialised. Code for those would probably
use char types a lot.
>>One other potential optimization - if you must make multiple references to
>>'putchar', then put it into a separate function of your own, such as
>>
>>void PutChar( int ch )
>>{
>> putchar( ch ) ;
>>}
>>
>>Since in many implementations, putchar() is a macro, referencing it
>>multiple times can/will cause code bloat.
>
>This leads to a useful technique: know the compiler and get familiar
>with generated code. Know the tradeoffs between code space and
>execution time.
OTOH one of the main strengths of C is its portability. Writing code to
optimise on one platform is generally a bad idea. It does however make
sense to get to know approaches that are likely to work well across many
platforms.
>Although putchar is, as Dan noted, typically implemented as a macro,
>it can be bypassed in favor of the library routine by surrounding the
>name in parentheses:
>
> (putchar) (out[index]);
>
>If the implementation doesn't have a separate library implementation,
>it isn't conforming to Standard C.
Right.
Bob Stout
c...@cts.com (Will Rose) wrote:
>: > Mix C is the worst C compiler I have seen. As a learning tool, I
>: >would recommend it highly on the basis of cost.
>: >
>: > Have you looked at the code it produces? I have.
It's not that bad, especially its floating point performance. It is a great
learning tool, though - the manual with its beginner's tutorial is worht the
price, so the compiler can be considered as free. Although it hasn't been
significantly updated in a while, there was a time when Power C was one of
the most ANSI-compliant compilers on the market.
>: It's a real horror show, alright, in that it generates a 40KB "Hello
>: World" or such. Almost as though it's a simulator written as a virtual
>: machine. If anybody wants my copy, they can have it for my cost to
>: ship it. $10 in the USA, a bit more elsewhere. I used it for one or
>: two days, and then found BDS-C !!
>Some confusion here - the Mix C I use generates a 3024 byte "Hello, world".
>And I thought BDS C was CP/M only? Certainly its non-standard libraries
>were a pain, tho' for CP/M-only stuff it was very nice.
Same size as I get. However, the BDS-C is a tipoff. Prior to Power C, Mix
produced a C compiler for CP/M (I still have copies of both Mix C and BDS-C
for my old Apple II w/ Z80 coprocessor board). I don't feel like dusting it
off to compare "Hello, world" file sizes, but if he's comparing with BDS-C,
it's likely he's comparing the *extremely old* CP/M version.
Colin W. Glenn
On 27 Dec 1996, Thad Smith wrote:
> There are many people that blur the distinction between C and C++
> because they are so similar or because they use only C++ and have
And I've found that out! The compiler definately uses ANSI C convention.
> >> it isn't conforming to Standard C.
> >How would one go about determining if the library conforms to C?
> That's a very difficult thing to do rigorously. There are commercial
> >Personally I've been trying to find a library tool on the net which would
The thought just occurred to me, the LIB is composed of OBJ files, they
don't make sense untill linked!
Also I found a tool called LIBRA, is opens a LIB file and shows what's
contained within the LIB. So I was able to browse the LIB and see
actually what functions it contains, though not able to extract any, it
required an external program for extracting/inserting them. The LIB I'm
using supports putchar(), it's code. Now I'm just looking for:
A) a program to extract/insert modules.
B) a file detailing how the LIB is constructed so I can build my own.
Thad Smith
In article <851729...@genesis.demon.co.uk>,
fr...@genesis.demon.co.uk (Lawrence Kirby) wrote:
>In article <LhtwyQ9y...@csn.net> Thad...@acm.org "Thad Smith" writes:
>
>>>#include <stdio.h>
>>>
>>>void main( void ) <---- only real old, real hacky unix types who
>>>*like* using cryptic debuggers don't use prototypes! :-)
>>
>>A nit here. Since this is the definition of a function, it is not a
>>prototype,
>
>It *is* a prototype. Prototype form was introduced in ANSI C and is the
>form that defines types in the parameter list. The prototype form when there
>are no parameters is a parameter list of just void as above.
I thank Lawrence for the corrections regarding prototypes.
>>There are many programmers that complain that main should never be
>>written with a void return value, but in the case of embedded systems,
>>a return value may simply not be used.
>
>Which doesn't make any difference. If you use the wrong return type main()
>may not even be called successfully, e.g. when function that return int
>have a different calling sequence to functions returning void. Even when
>the return value isn't used it is wrong to define main as returning void.
>> The C Standard even recognizes
>>this for freestanding implementations.
>
>C doesn't define main *at all* for freestanding implementations.
True. I should have said was that the C Standard doesn't require a
return value for main in freestanding environments because, as you
say, the means of program invocation are implementation-defined. I
had forgotten the issue of calling mechanism potentially being
different based on the distinction of int or void return value.
>>If no such declarations are
>>made, the compiler is free to optimize. Modern compilers that ignore
>>register declarations are not following the C precept of "trust the
>>programmer".
>
>The problem is that register is far too blunk an instrument for the purpose
>you are intending. Modern compilers can put different variables into
>registers at different times which is much more flexible than the register
>keyword could ever hope to be.
I recommend using "register" sparingly. Besides portability, C is
intended to allow programmers to produce efficient code for specific,
non-portable, applications. From the Rationale:
"C code can be non-portable. Although it strove to give programmers
the opportunity to write truly portable programs, the Committee did
not want to _force_ programmers into writing portable, to preclude the
user of C as a "high-level assembler": the ability to write
machine-specific code is one of the strengths of C." [1.1 Purpose]
It is particularly appropriate to readers in comp.arch.embedded to use
C as a high-level assembler. In cases where it is worth it (not
everything is), I normally compile straight-forward code,
look at the generated output, and if the results are poor I attempt to
optimize the output with source code changes, including use of
register declarations. Often that provides sufficient improvement so
that assembly language is not needed. Disallowing
programmer-specified register allocation is an opportunity lost.
I disagree that "register" is "far too blunt an instrument for the
purpose you are intending." My intent is obtaining better code from
the compiler, when needed. Here "better" might reflect reducing code
space or object space, but would more likely reflect run time in a
critical code section. Skilled use of register includes properly
organizing the code sequence and possibly declaring the register
variables within a small code block. In order to do this
intelligently, one must be familiar with the output of the compiler.
Obviously using register declarations willy-nilly (with a compiler
that pays attention) can result in worse code. Caveat programmer.
>>>The other trick, though not a lot of help in this particular case, is to
>>>use unsigned numbers where the value can't logically be signed. This helps
>>>a great deal on some processors, such as the 68K where a signed number
>>>often generates separate checks for greater than and for zero.
>>
>>Good point. It helps on 8-bit processors, too.
>
>8 bit targets are rather rare and specialised. Code for those would probably
>use char types a lot.
8 bit targets are not rare to many readers of comp.arch.embedded.
We do use char and unsigned char a lot.
>OTOH one of the main strengths of C is its portability. Writing code to
>optimise on one platform is generally a bad idea. It does however make
>sense to get to know approaches that are likely to work well across many
>platforms.
I agree that optimizing to specific platforms should not be done
without cause. Embedded applications typically have more need for
optimizations. A current application has 32k bytes of PROM and 2k
bytes of RAM. Because of this budget it is feasible to implement most
of the code in C, but I still need to be aware of memory utilization,
and in this particular case, optimize system timing in selected parts
of the code. My preferences, in order:
1. Generic, portable C
2. Standard C code rearranged to generate better code for the
implementation, e.g., selective use of register
3. C with implementation-defined extensions
4. Assembly
Context is important. It helps to know the few places that
optimization matters and leave implementation-specific techniques
out of the other modules.
Thad
Alicia Carla Longstreet
Richard Steven Walz wrote:
>
> In article <59uno8$o...@james.freenet.hamilton.on.ca>,
> Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote:
> >(Will Rose) wrote:
> >: Well, I use Mix C to compile MSDOS programs without especial difficulty.
> >
> >would recommend it highly on the basis of cost.
> >
> > Have you looked at the code it produces? I have.
> It's a real horror show, alright, in that it generates a 40KB "Hello
> World" or such. Almost as though it's a simulator written as a virtual
> machine. If anybody wants my copy, they can have it for my cost to
> ship it. $10 in the USA, a bit more elsewhere. I used it for one or
> two days, and then found BDS-C !!
I own Power C and the hello world program on my system is about 3Kb.
Power C beats every other MS-DOS C compiler I have ever used. I am
curious what code did you write to get a 40Kb hello world.
12-20-96 10:31 94 hello.c printf() version
12-20-96 10:33 3,136 HELLO.EXE
12-20-96 10:33 196 HELLO.MIX
12-20-96 10:36 92 Hello2.c puts() version
12-20-96 10:36 3,744 HELLO2.EXE
12-20-96 10:36 196 HELLO2.MIX
Alicia Carla Longstreet
You just can't have your cake and eat it twice.
Unless you get sick in between.
Ben Sauvin
That's a damn curious result, Alicia. Some questions, if you wouldn't
mind: do you have other compilers on hand to compare output sizes? Does
the example above use a custom printf() with 'unused modes removed'?
Which version of Power C did you use? Which makes, models and versions
of the other compilers did you use? Did they or did they not also have
custom printf() functions with 'unused modes removed'?
In other words, how you do that!?
--
Benoit A Sauvin
Anti-junk/spam device: underscore.
Scott Nudds
: >For reference, folks, I use a DOS C environment that _without_
: >any tweaking, produces a 3.4k executable for "Hello World".. 2k
: >of that is 'printf' support.
(Richard Steven Walz) wrote:
: This is So stupid! Can't a compiler be found that KNOWS a task is so
: simple that it only needs under 32 bytes??
No, you will find that the C startup code alone is close to 1000 bytes
long.
(Richard Steven Walz) wrote:
: I simply do NOT see why C
: has to be so stupid!! It is SUPPOSED to be so "close to assembler and
: yet high level", but I have yet to see it do either well!!
Indeed.
--
<---->
Scott Nudds
"Tim Behrendsen" wrote:
: Why do I care if a useless program like "Hello World" takes the minimum
: number of bytes? The fact is, 'printf' is capable of a lot more than
: just displaying a text string. This cost is negligable as a percentage
: of a real program.
Clearly because the problem this "useless program" so clearly
demonstrates is found in virtually every other function that C is used
to compile. It is clear evidence that C optimizes like shit.
It is clear that C pushers wish to ignore this fact.
--
<---->
Alicia Carla Longstreet
Ben Sauvin wrote:
>
> Alicia Carla Longstreet wrote:
> > I own Power C and the hello world program on my system is about 3Kb.
> > Power C beats every other MS-DOS C compiler I have ever used. I am
> > curious what code did you write to get a 40Kb hello world.
> >
> > 12-20-96 10:31 94 hello.c printf() version
> > 12-20-96 10:33 3,136 HELLO.EXE
> > 12-20-96 10:33 196 HELLO.MIX
> > 12-20-96 10:36 92 Hello2.c puts() version
> > 12-20-96 10:36 3,744 HELLO2.EXE
> > 12-20-96 10:36 196 HELLO2.MIX
> >
>
> That's a damn curious result, Alicia. Some questions, if you wouldn't
> mind: do you have other compilers on hand to compare output sizes? Does
> the example above use a custom printf() with 'unused modes removed'?
> Which version of Power C did you use? Which makes, models and versions
> of the other compilers did you use? Did they or did they not also have
> custom printf() functions with 'unused modes removed'?
>
> In other words, how you do that!?
Here is the source for printf() from Power C.
/* printf */
/* Copyright (c) Mix Software 1988 */
#include "stdio.h"
#include "stdarg.h"
#include "dos.h"
#define RAISE_NEAR_PTR 1
static signflag; /* signed value flag */
static plusflag; /* include + sign for positive
values */
static blankflag; /* include blank for positive values
*/
static poundflag; /* numeric format flag */
static upperflag; /* upper case flag for X, E & G
formats */
static ljflag; /* left justify flag */
static width; /* mimimum field width */
static precision; /* precision of numbers */
static farflag; /* far pointer flag used by _eint */
static farhalf; /* half of a far pointer */
static va_list parms; /* pointer to parameters */
static char padchar; /* pad character */
printf(fs) /* standard routine */
char *fs;
{
int fputc();
int _write();
int count;
extern _output(), ferror();
va_start(parms, fs);
count = _output(stdout, fs, fputc, _write);
return ferror(stdout) ? -1 : count;
}
fprintf(fp, fs) /* standard routine */
FILE *fp;
char *fs;
{
int fputc();
int _write();
int count;
extern _output(), ferror();
va_start(parms, fs);
count = _output(fp, fs, fputc, _write);
return ferror(fp) ? -1 : count;
}
sprintf(s,fs)
char *s;
char *fs;
{
int _mputc();
int _mwrite();
int count;
extern _output();
va_start(parms,fs);
count = _output(&s, fs, _mputc, _mwrite);
*s = '\0';
return count;
}
cprintf(fs)
char *fs;
{
int putch();
int _cwrite();
extern _output();
va_start(parms, fs);
return _output(NULL, fs, putch, _cwrite);
}
vprintf(fs, argptr) /* standard routine */
char *fs;
char *argptr;
{
int fputc();
int _write();
int count;
extern _output(), ferror();
parms = argptr;
count = _output(stdout, fs, fputc, _write);
return ferror(stdout) ? -1 : count;
}
vfprintf(fp, fs, argptr) /* standard routine */
FILE *fp;
char *fs;
char *argptr;
{
int fputc();
int _write();
int count;
extern _output(), ferror();
parms = argptr;
count = _output(fp, fs, fputc, _write);
return ferror(fp) ? -1 : count;
}
vsprintf(s, fs, argptr) /* standard routine */
char *s;
char *fs;
char *argptr;
{
int _mputc();
int _mwrite();
int count;
extern _output();
parms = argptr;
count = _output(&s, fs, _mputc, _mwrite);
*s = '\0';
return count;
}
_output(fp, format, putc, write) /* output routine for */
/* printf, sprintf, fprintf */
char *fp; /* pointer to destination */
char *format; /* pointer to format string */
int (*putc)(); /* pointer to output function */
int (*write)(); /* pointer to output function */
{
char *bufptr; /* pointer into buffer */
char c; /* current character */
int count=0; /* count of characters output */
int longflag; /* long ("l") present in format */
int Nflag; /* near pointer flag */
int Fflag; /* far pointer flag */
int length; /* length of output string */
int flag; /* ftoa edit flag */
int left; /* number digits left of decimal */
int right; /* number digits right of decimal */
char buffer[255]; /* encode buffer */
char null[]="(null)"; /* print this for %s with NULL
pointer */
STRING *dynamic; /* dynamic string pointer */
void (*enc)(); /* pointer to encode function */
void _eint(); /* encode integer function */
void _elong(); /* encode long function */
int _atoi(); /* convert string to integer */
int _ftoaflag(); /* get format flag for ftoa function
*/
int strlen(); /* determine length of string */
int strcpy(); /* copy a string */
#ifndef M_I86LM
char far *fbufptr; /* far pointer into buffer */
int len; /* length of output string */
int _fstrlen(); /* determine length of far string */
int _fmemcpy(); /* memcpy with far pointers */
#endif
void ftoa(); /* float to ascii */
while (c = *format) {
if (c != '%') {
(*putc)(c,fp);
count++;
format++;
continue;
}
precision = -1;
bufptr = buffer;
ljflag = signflag = blankflag = poundflag = longflag
= upperflag = plusflag = Nflag = Fflag = 0;
flags: switch (*(++format)) {
case '-': ++ljflag; goto flags;
case '+': ++plusflag; goto flags;
case ' ': ++blankflag; goto flags;
case '#': ++poundflag; goto flags;
}
padchar = (*format == '0') ? '0' : ' ';
if (*format == '*') {
++format;
if ((width = va_arg(parms, int)) < 0) {
width = -width;
++ljflag;
}
}
else width = _atoi(&format);
if ((*format) == '.') {
++format;
if (*format == '*') {
++format;
precision = va_arg(parms, int);
}
else precision = _atoi(&format);
}
enc = _eint;
if (((c = *format++) == 'l') || c == 'L') {
c = *format++;
enc = _elong;
longflag++;
}
else if (c == 'h') c = *format++;
else if (c == 'N') {
Nflag++;
c = *format++;
}
else if (c == 'F') {
Fflag++;
c = *format++;
}
switch(c) {
case 'i': /* signed decimal */
case 'd':
signflag++;
(*enc)(buffer, 10);
length = strlen(bufptr);
break;
case 'u': /* unsigned decimal */
(*enc)(buffer, 10);
length = strlen(bufptr);
break;
case 'o': /* unsigned octal */
(*enc)(buffer, 8);
length = strlen(bufptr);
break;
case 'X': upperflag++; /* unsigned hexadecimal */
case 'x':
(*enc)(buffer, 16);
length = strlen(bufptr);
break;
case 'p': /* pointer */
precision = 4;
upperflag++;
poundflag = 0;
#ifdef M_I86LM
if (Nflag) {
#ifdef RAISE_NEAR_PTR
farflag++;
bufptr = va_arg(parms, char*);
farhalf = FP_OFF(bufptr);
bufptr = buffer;
#endif
_eint(buffer, 16);
farflag = 0;
length = 4;
}
else {
farflag++;
bufptr = va_arg(parms, char*);
farhalf = FP_SEG(bufptr);
_eint(buffer, 16);
buffer[4] = ':';
farhalf = FP_OFF(bufptr);
bufptr = buffer;
_eint(buffer + 5, 16);
length = 9;
farflag = 0;
}
#else
if (Fflag) {
farflag++;
fbufptr = va_arg(parms, char far*);
farhalf = FP_SEG(fbufptr);
_eint(buffer, 16);
buffer[4] = ':';
farhalf = FP_OFF(fbufptr);
_eint(buffer + 5, 16);
length = 9;
farflag = 0;
}
else {
_eint(buffer, 16);
length = 4;
}
#endif
break;
case 's': /* string */
#ifdef M_I86LM
padchar = ' ';
#ifndef RAISE_NEAR_PTR
if (Nflag) bufptr = va_arg(parms, char near*);
else
#endif
bufptr = va_arg(parms, char*);
if (bufptr == NULL) {
bufptr = null;
length = 6;
break;
}
length = strlen(bufptr);
if (precision >= 0 && length > precision)
length = precision;
break;
#else
padchar = ' ';
if (Fflag) {
fbufptr = va_arg(parms, char far*);
if (fbufptr == NULL) {
bufptr = null;
length = 6;
break;
}
length = _fstrlen(fbufptr);
if (precision >= 0 && length > precision)
length = precision;
width = width - length;
if (!ljflag) {
c = *fbufptr;
if (padchar == '0' && (c == '-' || c ==
'+')) {
--length;
(*putc)(c, fp);
fbufptr++;
count++;
}
while (width-- > 0) {
(*putc)(padchar, fp);
count++;
}
}
while (length > 0) {
len = length < 256 ? length : 255;
_fmemcpy((char far*) buffer, fbufptr, len);
(*write)(fp, buffer, len);
count += len;
fbufptr += len;
length -= len;
}
while (width-- > 0) {
(*putc)(padchar,fp);
count++;
}
continue;
}
else {
bufptr = va_arg(parms, char*);
if (bufptr == NULL) {
bufptr = null;
length = 6;
break;
}
length = strlen(bufptr);
if (precision >= 0 && length > precision)
length = precision;
break;
}
#endif
case 'c': /* character */
padchar = ' ';
buffer[0] = (char) va_arg(parms, int);
buffer[1] = '\0';
length = 1;
break;
case 'E': upperflag++; /* exponential */
case 'e':
flag = 1;
goto reals;
case 'G': upperflag++; /* no trailing 0's */
case 'g':
/* fixed or exponential? */
if (precision < 0) precision = 6;
flag = _ftoaflag(parms, poundflag, precision);
goto reals;
case 'f': /* fixed point */
flag = 0;
reals:
if (plusflag) flag |= 8;
else if (blankflag) flag |= 136;
if (precision < 0) right = 6;
else right = precision;
left = 1;
ftoa(va_arg(parms, double), bufptr, flag, left,
right);
length = 0;
while (c=buffer[length]) {
if (poundflag == 0) {
if (c == '.' && precision == 0) {
strcpy(&buffer[length],
&buffer[length+1]);
continue;
}
}
if (c == 'e' && upperflag) buffer[length] =
'E';
else if (c == 'E' && !upperflag) buffer[length]
= 'e';
++length;
}
break;
case 'n':
*(va_arg(parms, int*)) = count;
continue;
case 'y': /* dynamic string */
dynamic = va_arg(parms, STRING*);
length = dynamic->length;
bufptr = dynamic->string;
break;
default : /* format string character */
(*putc)(c, fp);
count++;
continue;
}
width = width - length;
if (!ljflag) {
if (padchar == '0' && (*bufptr == '-' || *bufptr == '+')) {
--length;
(*putc)(*bufptr++, fp);
count++;
}
while (width-- > 0) {
(*putc)(padchar, fp);
count++;
}
}
(*write)(fp,bufptr,length);
count += length;
while (width-- > 0) {
(*putc)(' ',fp);
count++;
}
}
return count;
}
void _eint(bufptr, base) /* encode an integer */
char *bufptr; /* pointer to encode buffer */
int base; /* number base */
{
extern int strlen();
extern char *strcpy();
char buffer[7];
void _dtoa(), _htoa(), _otoa();
char *ptr = buffer;
char *bufstart = bufptr;
int i, length, zfill = 0;
if (farflag) i = farhalf;
else i = va_arg(parms, int);
if (precision == 0 && i == 0) *bufptr = '\0';
else {
if (base == 10) {
if (signflag) {
if (i < 0) {
*bufptr++ = '-';
i = -i;
}
else if (plusflag) *bufptr++ = '+';
else if (blankflag) *bufptr++ = ' ';
}
_dtoa(i, &ptr);
}
else if (base == 16) {
if (poundflag && i) {
*bufptr++ = '0';
*bufptr++ = upperflag ? 'X' : 'x';
if (padchar == '0' && !ljflag) zfill++;
}
_htoa(i, &ptr);
}
else {
if (poundflag && i) {
*bufptr++ = '0';
}
_otoa(i, &ptr);
}
*ptr = '\0';
length = strlen(buffer);
if (precision > 255) precision = 255;
for (i=precision-length; i > 0; i--) *bufptr++ = '0';
if (zfill) {
if (width > 255) width = 255;
for (i = width - (int)(bufptr - bufstart + length); i > 0;
i--)
*bufptr++ = '0';
}
*bufptr = '\0';
strcpy(bufptr, buffer);
}
}
void _dtoa(n, bufptr) /* decimal integer encode routine */
unsigned n; /* unsigned integer */
char **bufptr; /* pointer to the buffer pointer */
{
if (n < 10) *(*bufptr)++ = (char)(n + 48);
else {
_dtoa(n/10, bufptr);
_dtoa(n%10, bufptr);
}
}
void _htoa(n, bufptr) /* hexadecimal integer encode
routine */
unsigned n; /* unsigned integer */
char **bufptr; /* pointer to the buffer pointer */
{
if (n < 16) {
if (n < 10) *(*bufptr)++ = (char)(n + 48);
else *(*bufptr)++ = (char)(upperflag ? n + 55 : n + 87);
}
else {
_htoa(n/16, bufptr);
_htoa(n%16, bufptr);
}
}
void _otoa(n, bufptr) /* octal integer encode routine */
unsigned n; /* unsigned integer */
char **bufptr; /* pointer to the buffer pointer */
{
if (n < 8) *(*bufptr)++ = (char)(n + 48);
else {
_otoa(n/8, bufptr);
_otoa(n%8, bufptr);
}
}
void _elong(bufptr, base) /* encode a long */
char *bufptr; /* pointer to encode buffer */
int base; /* number base */
{
char buffer[12];
char *ptr = buffer;
char *bufstart = bufptr;
int i, length, zfill = 0;
long l;
extern void _ldtoa(), _lhtoa(), _lotoa();
extern int strlen();
extern char *strcpy();
l = va_arg(parms, long);
if (precision == 0 && l == 0) *bufptr = '\0';
else {
if (base == 10) {
if (signflag) {
if (l < 0) {
*bufptr++ = '-';
l = -l;
}
else if (plusflag) *bufptr++ = '+';
else if (blankflag) *bufptr++ = ' ';
}
_ldtoa(l, &ptr);
}
else if (base == 16) {
if (poundflag && l) {
*bufptr++ = '0';
*bufptr++ = upperflag ? 'X' : 'x';
if (padchar == '0' && !ljflag) zfill++;
}
_lhtoa(l, &ptr);
}
else {
if (poundflag && l) {
*bufptr++ = '0';
}
_lotoa(l, &ptr);
}
*ptr = '\0';
length = strlen(buffer);
if (precision > 255) precision = 255;
for (i=precision-length; i > 0; i--) *bufptr++ = '0';
if (zfill) {
if (width > 255) width = 255;
for (i = width - (int)(bufptr - bufstart + length); i > 0;
i--)
*bufptr++ = '0';
}
*bufptr = '\0';
strcpy(bufptr, buffer);
}
}
void _ldtoa(l, bufptr) /* long decimal encode routine */
unsigned long l; /* long integer */
char **bufptr; /* pointer to the buffer pointer */
{
if (l < 10) *(*bufptr)++ = (char)(l + 48);
else {
_ldtoa(l/10, bufptr);
_ldtoa(l%10, bufptr);
}
}
void _lhtoa(l, bufptr) /* long hexadecimal encode routine
*/
long l; /* long integer */
char **bufptr; /* pointer to the buffer pointer */
{
int i, start;
int digit[9];
digit[8] = 1;
for (i = 7; i >= 0; i--) {
digit[i] = (int)(l & 0xf);
l = l >> 4;
}
start = 0;
while (digit[start] == 0) start++;
if (start == 8) *(*bufptr)++ = '0';
else {
for (i = start; i < 8; i++) {
if (digit[i] < 10) *(*bufptr)++ = (char)(digit[i] + 48);
else *(*bufptr)++ = (char)(upperflag ? digit[i] + 55 : digit[i]
+ 87);
}
}
}
void _lotoa(l, bufptr) /* long octal encode routine */
long l; /* long integer */
char **bufptr; /* pointer to the buffer pointer */
{
int i, start;
int digit[12];
digit[11] = 1;
for (i = 10; i > 0; i--) {
digit[i] = (int)(l & 7);
l = l >> 3;
}
digit[0] = (int)(l & 3);
start = 0;
while (digit[start] == 0) start++;
if (start == 11) *(*bufptr)++ = '0';
else {
for (i = start; i < 11; i++)
*(*bufptr)++ = (char)(digit[i] + 48);
}
}
_mputc(c, fp) /* write c to fp */
int c;
char **fp;
{
*(*fp)++ = (char) c;
return c;
}
_mwrite(fp, s, n)
char **fp;
char *s;
int n;
{
int i;
for (i=0; i < n; i++) *(*fp)++ = *s++;
return n;
}
_cwrite(fp, s, n)
char **fp;
char *s;
int n;
{
int i;
extern void putch();
for (i=0; i < n; i++) putch(*s++);
return n;
fp;
return n;
}
Please keep in mind copyright rules, if you want the source Mix Software
sells it for $10.00 plus S&H.
Mix Software
1132 Commerce Drive
Richardson, Tx 75081
(214)783-6001
I believe that it fully supports the ANSI Standard, and IEEE floating
point conventions, since it was written in 1988, this should be true.
BTW, this is the latest version of the Compiler and Standard Source that
Mix sells.
Alicia Carla Longstreet
Know then thy compiler, seek not Gates to scan,
the proper study of programmers is the standard.
Alicia Longstreet
P.S. I would be very interested to know if the above code does NOT
conform to the standard.
Ben Sauvin
It would be more accurate to say that most C programmers, particularly
those who DO have knowledge of assembly language, are well aware of the
fact that their implementations of the language will not generally
optimise for size or speed quite as well as hand-crafted assembler. The
choice between the two languages have less to do with saving a few bytes
and more to saving a few months of development time.
Since Nudds does not recognise the pressures of delivering product
under deadline (indeed, since he has clearly stated that such pressures
are irrelevent), his opinion could not be said to carry much weight in
such matters. Experienced and trained coders and engineers are
altogether too keenly conscious of the fact that development in assembly
is 5 to 20 times that of development in C.
Perhaps Nudds' only practical experience with the C programming
language WAS his initial 'Hello World' program.
Mitchell Schoenbrun
: The Watcom C compiler (v 9.51) for the QNX operating system generates
: about a 4k executable for your basic "Hello World" program using
: printf() and no special tweaking or linking. I realize this isn't a
: fair comparison since its a different OS but I thought it was
: intersting. BTW, the C++ equivelent (using cout <<) was something
: like 25k I think. yech.
It might really not be fare. QNX has a shared library that might
be helping reduce code.
--
Mitchell Schoenbrun --------- masc...@pobox.com
Alicia Carla Longstreet
Ben Sauvin wrote:
[snip out worthless S. N***s comments]
> Perhaps Nudds' only practical experience with the C programming
> language WAS his initial 'Hello World' program.
> --
Yes but his version wasn't portable, and it had a bug in it.
Alicia Carla Longstreet
"This has got to be the stupidest man alive."
"Lets shoot him and put him out of his misery."
from Ruthless People.
Alicia Carla Longstreet
Scott Nudds wrote:
>:> For reference, folks, I use a DOS C environment that _without_
>:> any tweaking, produces a 3.4k executable for "Hello World".. 2k
>:> of that is 'printf' support.
> (Richard Steven Walz) wrote:
>: This is So stupid! Can't a compiler be found that KNOWS a task is so
>: simple that it only needs under 32 bytes??
Tell me Richard, does your assembler eliminate code bloat when you plug
in one of the generalized functions from your personal library, or do
you streamline it yourself. I have a copy of the Standard Library with
one of my compilers, when I need to produce the smallest, fastest,
tightest code posible, I simply create a streamlined version of any or
all of the standard library functions that I am using. I can even
streamline the start-up code when needed. Of course, I never do this
lightly, but sometimes, in the interest of portability it becomes the
best solution.
> No, you will find that the C startup code alone is close to 1000 bytes
> long.
1K of startup code on a 1 megabyte project is nothing, the time savings
from using printf() is well worth the code it produces.
This, by the way, is called generalizing a function, we accept some code
bloat as a trade off for a function that is useful in many different
areas. Of course, the only way you could approach the development time
of C in assembler would be to have a great deal of prewritten code and
macros ready to use. The fact that you decry a generalized function to
improve usefullness, is indicative of your lack of such a prewritten
library.
BTW, 2K of printf() support in a 1 megabyte project is pretty
insignificant as well.
It is easy to show the 'superiority' of assembler in producing smaller
code with small trvial programs like Hello World. In these the 'bloat'
(gnerealized code) is often larger than the actual code, but unlike Mr
Nudds we don't write trivial programs.
> (Richard Steven Walz) wrote:
>: I simply do NOT see why C has to be so stupid!! It is SUPPOSED
>: to be so "close to assembler and yet high level", but I have yet
>: to see it do either well!!
C is very close to assembler, C ompilers jsut don't bother with trivial
optimizations in trivial programs. Why would I care to spend the time
to eliminate unwanted support for unneeded functionality in a trivial
program like printf() and in a 200Kb program like the one I wrote to
interface an Unix mail system with cc:mail on a Novell network, what is
the point. It would be a total waste of time to rewrite printf() to
save 2K on a 200K program.
Dave Baldwin
I figure anyone who's still arguing about 'Hello World.' isn't doing
anything useful anyway.
--
-=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=-
Dave Baldwin: dib...@netcom.com | The Computer Journal 1(800)424-8825
DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/"
Voice : (916) 722-3877 | Hands-on hardware and software
TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480
-=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=-
Will Rose
Scott Nudds (af...@james.freenet.hamilton.on.ca) wrote:
: "Tim Behrendsen" wrote:
: : Why do I care if a useless program like "Hello World" takes the minimum
: : number of bytes? The fact is, 'printf' is capable of a lot more than
: : just displaying a text string. This cost is negligable as a percentage
: : of a real program.
: Clearly because the problem this "useless program" so clearly
: demonstrates is found in virtually every other function that C is used
: to compile. It is clear evidence that C optimizes like shit.
: It is clear that C pushers wish to ignore this fact.
The size of the stdio library has always been a known problem, which
is why you needn't include it. If I just use read() and write(), I get
a Hello, world binary of around 1K, and most of that is the C runtime.
Adding stdio.h and using printf() gets me an 8K binary. C compilers
optimise pretty well these days, and if you don't include large libraries
then you won't get large binaries.
Ben Sauvin
Mitchell Schoenbrun wrote:
>
> : The Watcom C compiler (v 9.51) for the QNX operating system generates
> : about a 4k executable for your basic "Hello World" program using
> : printf() and no special tweaking or linking. I realize this isn't a
> : fair comparison since its a different OS but I thought it was
> : intersting. BTW, the C++ equivelent (using cout <<) was something
> : like 25k I think. yech.
>
> It might really not be fare. QNX has a shared library that might
> be helping reduce code.
If size or speed is an issue, and portability isn't, anybody who uses
the standard libraries without a second thought isn't thinking to begin
with. Other considerations may apply, too: it's well known that the DOS
interrupt 21h isn't reentrant, so when I need to print something to the
screen from within an intercepted timer tick interrupt, I'll either
write it directly to screen memory or use a BIOS call (which DOESN'T
care), and I'll generally compose this kind of code with inline
assembly.
The trick is in knowing there the bloat is likely to be, deciding when
it matters (and when it doesn't), and either knowing or being able to
figure out how to do an end-run around the standard libraries.
--
Benoit A Sauvin
Anti-junk/spam device: underscore.
"It should be clear however, that with a sufficiently
complex preprocessor, it is entirely possible to exactly
emulate any compiled language. Compilers are exactly this
kind of preprocessor." - Scott Nudds
Lawrence Kirby
In article <KnaxyQ9y...@csn.net> Thad...@acm.org "Thad Smith" writes:
...
>It is particularly appropriate to readers in comp.arch.embedded to use
>C as a high-level assembler.
Yes, I accept that programming for embedded environments does have its
specialised requirements. I was forgetting where this thread was being
cross-posted to.
> In cases where it is worth it (not
>everything is), I normally compile straight-forward code,
>look at the generated output, and if the results are poor I attempt to
>optimize the output with source code changes, including use of
>register declarations. Often that provides sufficient improvement so
>that assembly language is not needed. Disallowing
>programmer-specified register allocation is an opportunity lost.
I suspect this is more likely to be an issue given the types of compiler
and archetecture commonly used in embedded systems.
...
>I agree that optimizing to specific platforms should not be done
>without cause. Embedded applications typically have more need for
>optimizations. A current application has 32k bytes of PROM and 2k
>bytes of RAM. Because of this budget it is feasible to implement most
>of the code in C, but I still need to be aware of memory utilization,
>and in this particular case, optimize system timing in selected parts
>of the code. My preferences, in order:
>
>1. Generic, portable C
>2. Standard C code rearranged to generate better code for the
>implementation, e.g., selective use of register
>3. C with implementation-defined extensions
>4. Assembly
That looks reasonable.
Chris Torek
In article <32C6CA...@ici.net> Alicia Carla Longstreet <ca...@ici.net>
posts:
>... the source for printf() from Power C.
>printf(fs) /* standard routine */
>char *fs;
>{
...
>vprintf(fs, argptr) /* standard routine */
>char *fs;
>char *argptr;
>{
[and much more]
>I believe that it fully supports the ANSI Standard, and IEEE floating
>point conventions, since it was written in 1988, this should be true.
Actually, if it was written before 1990 (and the copyright date of
1988 suggests that it was), it cannot have been based on the final
version of the C Standard. (The IEEE FP standard has been around
longer; I am not sure when it was adopted. None of the FP conversion
code was included, though, so there is not much one can say here.)
>P.S. I would be very interested to know if the above code does NOT
>conform to the standard.
It definitely does not.
I did not study the code closely, but it appears to limit integer
precision to at most 255 characters, while the Standard requires
a conversion to be able to produce up to 509 characters (ANSI
classic, section 4.9.6.1, p. 135, ll. 17--18). (This should be
easy enough to fix.)
It certainly is not strictly conformant `user' code. The two
fragments I quoted violate the name space (the names printf and
vprintf are reserved to the implementation), but this is minor
since they are *part* of the implementation (i.e., anyone working
on this Power C printf is wearing an implementors' hat and is thus
allowed, or in this case even required, to use these names). It
does, however, mean that if you work on this code, in any way, you
are a `Power C Implementor', not a `C Programmer'. The distinction
is important since the quoted printf() will *not* work on other
systems. (For instance, it will not work on any of my systems,
for reasons that I think would take too long to explain here.) As
an implementor, your task changes from `writing conformant code'
to `writing implementation-specific code that makes your implementation
connect up to conformant user code'; as such, you are allowed, and
often required, to make use of implementation-defined and undefined
behavior (such as converting a `void *' pointer to some kind of
integer in order to convert a %p format, or defining symbols like
printf).
Another way in which the quoted code fails to conform, and this
one is much more important, is that the argument types are incorrect.
The first argument to printf (`fs' above) should have type `const
char *', and the function must be declared (and hence should probably
be defined) using prototype syntax; and the arguments to vfprintf
should be `const char *' and `va_list' respectively. `char *argptr'
in particular is egregious -- there is no reason to use `char *'
rather than `va_list', and doing so will make the example fail even
to compile on the Pyramid and the PowerPC, where va_list is
significantly different from `char *'. In other words, even with
an implementor's hat on, we can write code that moves smoothly from
one implementation to the next in this case. We may need #ifdefs
or something equally ugly for `%p', but we can avoid them here.
Much of the remainder of the code also makes use of implementor
namespace symbols (for reasons that should now be obvious).
While the C Standard does not require this, the example code is
also not reentrant, and cannot be used on, for instance, a system
that intends to support POSIX threads.
(My own stdio is available in any of the various BSDs, if anyone
wants to see that. Note that the printf engine is only partly my
own work; its overall design is due to Keith Bostic. If you obtain
this as part of NetBSD or FreeBSD, it is not unlikely that someone
has changed my code as well.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: to...@bsdi.com +1 510 234 3167
Thad Smith
In article <5aef0j$k...@elf.bsdi.com>, to...@elf.bsdi.com (Chris Torek) wrote:
>In article <32C6CA...@ici.net> Alicia Carla Longstreet <ca...@ici.net>
>posts:
>>... the source for printf() from Power C.
>
>>printf(fs) /* standard routine */
>>char *fs;
>>{
> ...
>
>>vprintf(fs, argptr) /* standard routine */
>>char *fs;
>>char *argptr;
>>{
>
>[and much more]
>>I believe that it fully supports the ANSI Standard, and IEEE floating
>>point conventions, since it was written in 1988, this should be true.
>Another way in which the quoted code fails to conform, and this
>one is much more important, is that the argument types are incorrect.
>The first argument to printf (`fs' above) should have type `const
>char *', and the function must be declared (and hence should probably
>be defined) using prototype syntax; and the arguments to vfprintf
>should be `const char *' and `va_list' respectively.
That point is relevant to the prototype supplied in the standard
headers, but cannot be a defect in the library implementation as long
as the routines perform properly. What if the routines were coded in
assembly language? Certainly there you would not expect to see a
declaration of va_list in the implementation.
`char *argptr'
>in particular is egregious -- there is no reason to use `char *'
>rather than `va_list', and doing so will make the example fail even
>to compile on the Pyramid and the PowerPC, where va_list is
>significantly different from `char *'.
While a more portable implementation could be written, that probably
wasn't the objective of this implemenation. Short-sighted? Possibly,
but the implementor was probably more interested in getting out this
implmentation on time, rather than coding portably. Since 1988, I
don't think they have attempted to port the compiler to another
architecture.
Thad
Scott Nudds
Ben Sauvin <sau...@csql.mv.com> wrote:
: If THAT is the basis on which you found your hatred of the C
: programming language, it's small wonder!
It is not the basis. The best C compilers produce code that is shit.
--
<---->
Scott Copeland
Scott Nudds wrote:
>
> It is clear that C pushers wish to ignore this fact.
For more of Nudds' witty comments, see comp.lang.asm.x86....
Scott Copeland
R&D Engineer
Grammar Engine Inc.
Scott Copeland
Scott Copeland
Scott Copeland
Jerry Coffin
In article <5aef0j$k...@elf.bsdi.com>, to...@elf.bsdi.com says...
[ ... ]
> Actually, if it was written before 1990 (and the copyright date of
> 1988 suggests that it was), it cannot have been based on the final
> version of the C Standard. (The IEEE FP standard has been around
> longer; I am not sure when it was adopted. None of the FP
> conversion code was included, though, so there is not much one can
> say here.)
IEEE 754 was adopted in 1985.
--
Later,
Jerry.
Scott Nudds
Alicia Carla Longstreet <ca...@ici.net> wrote:
: I own Power C and the hello world program on my system is about 3Kb.
: Power C beats every other MS-DOS C compiler I have ever used. I am
: curious what code did you write to get a 40Kb hello world.
In assembler, Hello world clocks in at around 25 bytes. Alicia tells
us that a C compiler that "beats every other MS-DOS C compiler" she has
ever used produces an executable that is 100 times larger.
Clearly this is good evidence that C optimizes like shit.
--
<---->
Scott Nudds
Ben Sauvin <sau...@csql.mv.com> wrote:
: It would be more accurate to say that most C programmers, particularly
: those who DO have knowledge of assembly language, are well aware of the
: fact that their implementations of the language will not generally
: optimise for size or speed quite as well as hand-crafted assembler. The
: choice between the two languages have less to do with saving a few bytes
: and more to saving a few months of development time.
Yet Sauvin has admitted that programming in assembler need take no
more time than programming in a HLL.
It is obvious that this should be the case.
Ben Sauvin <sau...@csql.mv.com> wrote:
: Experienced and trained coders and engineers are
: altogether too keenly conscious of the fact that development in assembly
: is 5 to 20 times that of development in C.
Former factor worker Sauvin should be bright enough to realize that
programming speed is a function of the ease with which a method can be
implemented in software. This is in turn basically a function of
syntax. Assembler can be made to have virtually any syntax, and
therefore programs can be written in assembler just as fast as they can
be written in any HLL language.
Sauvin sees only what his religion allows him to see.
--
<---->
Jim Neil
In article <5atnsa$n...@james.freenet.hamilton.on.ca>, af...@james.freenet.hamilton.on.ca (Scott Nudds) says:
>
>Alicia Carla Longstreet <ca...@ici.net> wrote:
>: I own Power C and the hello world program on my system is about 3Kb.
>: Power C beats every other MS-DOS C compiler I have ever used. I am
>: curious what code did you write to get a 40Kb hello world.
>
> In assembler, Hello world clocks in at around 25 bytes. Alicia tells
>us that a C compiler that "beats every other MS-DOS C compiler" she has
>ever used produces an executable that is 100 times larger.
25 bytes? Well Scott, everybody knows it can be done in 21 bytes!
25 bytes is 19% bigger than it needs to be! Here it is, and it is in
a compiled language, TERSE.
main Group code,data; \ code & data become 1 seg, code first.
Assume cs:main,ds:main,ss:main;\ tell assembler what's in the seg regs.
code Segment byte; \ open code segment.
Org 100h; \ all .COM programs start at 100h
data Segment byte; \ open data segment.
' msg ="Hello World$"; \ declare the data.
data EndS; \ close data segment.
Start: \ program starts here.
dx = Offset main:msg; \ dx = offset of msg relative to main.
ah = 9; !21h; \ output the message.
!20h; \ terminate program.
code EndS; \ close code segment.
End Start; \ program begins at start.
Jim Neil ___ ___/ ____/ ___ / ____/ ____/
Creator of The / / / / / /
TERSE Programming Language / ___/ ___/ ____ / ___/
ISBN: 0-9652660-0-1 / / / \ / /
jim-...@digital.net __/ ______/ __/ __\ ______/ ______/ TM
http://www.terse.com
Scott Nudds
: optimizations in trivial programs.
But as Alicia Carla Longstreet has seen and continues to ignore,
programs in C are 2 or more times larger and 2 or more times slower than
their optimal assembly counterparts.
C pushers like Alicia keep repeating the same ignorance over and over
again in an effort to convince themselves and others that the lie is
truth.
Alicia Carla Longstreet <ca...@ici.net> wrote:
: Why would I care to spend the time
: to eliminate unwanted support for unneeded functionality in a trivial
: program like printf() and in a 200Kb program like the one I wrote to
: interface an Unix mail system with cc:mail on a Novell network, what is
: the point.
A competent assembly programmer should be able to accomplish the same
task in 1/10th the size, and generate a program that runs 2 or more
times faster.
--
<---->
Scott Nudds
(Dave Baldwin) wrote:
: I figure anyone who's still arguing about 'Hello World.' isn't doing
: anything useful anyway.
C pushers dredge this program up from time to time in an attempt to
drive the subject off course. The fact is, most other C programs
optimize equally poorly. Typically producing execuatables that run 2 or
more times slower than optimal code and which are 2 or more times larger
than necessary.
--
<---->
Scott Nudds
: : "Tim Behrendsen" wrote:
: : : Why do I care if a useless program like "Hello World" takes the minimum
: : : number of bytes? The fact is, 'printf' is capable of a lot more than
: : : just displaying a text string. This cost is negligable as a percentage
: : : of a real program.
Scott Nudds wrote:
: : Clearly because the problem this "useless program" so clearly
: : demonstrates is found in virtually every other function that C is used
: : to compile. It is clear evidence that C optimizes like shit.
(Will Rose) wrote:
: The size of the stdio library has always been a known problem, which
: is why you needn't include it. If I just use read() and write(), I get
: a Hello, world binary of around 1K, and most of that is the C runtime.
Even your minimum size of 1K is 30+ times larger than needed.
(Will Rose) wrote:
: C compilers
: optimise pretty well these days, and if you don't include large libraries
: then you won't get large binaries.
And as we have seen, this claim is a fiction. C compilers have made
minor improvements over the decades but any competent individual who has
looked at their output can tell you, they still optimize like shit.
Those who claim otherwise have not looked, or are not competent
enough to know what is and is not optimal.
--
<---->
Ben Sauvin
Scott Nudds wrote:
>
> Ben Sauvin <sau...@csql.mv.com> wrote:
> : It would be more accurate to say that most C programmers, particularly
> : those who DO have knowledge of assembly language, are well aware of the
> : fact that their implementations of the language will not generally
> : optimise for size or speed quite as well as hand-crafted assembler. The
> : choice between the two languages have less to do with saving a few bytes
> : and more to saving a few months of development time.
>
> Yet Sauvin has admitted that programming in assembler need take no
> more time than programming in a HLL.
Ben Sauvin has never admitted any such thing as a general case. Scott
Nudds confuses observation of a single case with generalisation.
> It is obvious that this should be the case.
>
> Ben Sauvin <sau...@csql.mv.com> wrote:
> : Experienced and trained coders and engineers are
> : altogether too keenly conscious of the fact that development in assembly
> : is 5 to 20 times that of development in C.
>
> Former factor worker Sauvin should be bright enough to realize that
> programming speed is a function of the ease with which a method can be
> implemented in software. This is in turn basically a function of
> syntax. Assembler can be made to have virtually any syntax, and
> therefore programs can be written in assembler just as fast as they can
> be written in any HLL language.
>
> Sauvin sees only what his religion allows him to see.
And one presumes that Scott Nudds alone has enlightened perspective?
Fascinating that one so devoted to games development can make such
sweeping statements; perhaps he can come optimise my engineering
department for me.
Tim Behrendsen
Scott Nudds <af...@james.freenet.hamilton.on.ca> wrote in article
<5atnst$n...@james.freenet.hamilton.on.ca>...
> Alicia Carla Longstreet <ca...@ici.net> wrote:
> : Why would I care to spend the time
> : to eliminate unwanted support for unneeded functionality in a trivial
> : program like printf() and in a 200Kb program like the one I wrote to
> : interface an Unix mail system with cc:mail on a Novell network, what is
> : the point.
>
> A competent assembly programmer should be able to accomplish the same
> task in 1/10th the size, and generate a program that runs 2 or more
> times faster.
Prove it. Let's see a completely compliant printf subroutine that is
1/10th the size, and twice as fast. Come, come, Nudds, surely you
wouldn't make an assertion without being able to back it up?
--
==========================================================================
| Tim Behrendsen (t...@a-sis.com) | http://www.cerfnet.com/~timb |
| "Judge all, and be prepared to be judged by all." |
==========================================================================
Clyde Smith-Stubbs
> In assembler, Hello world clocks in at around 25 bytes. Alicia tells
> us that a C compiler that "beats every other MS-DOS C compiler" she has
> ever used produces an executable that is 100 times larger.
>
Hardly. Since this discussion is being carried in comp.arch.embedded amongst
others, I offer here a C program for an embedded system implementing
"Hello world" in much the same way an assembler programmer might write
it. The compiled code, also attached, is 44 bytes long - including the
initialization of the UART.
How many bytes could an assembler programmer shave off this? Not too
many - there just aren't many to spare!
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411
cl...@htsoft.com | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA. |
----------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.htsoft.com, or email in...@htsoft.com.
Will Rose
Scott Nudds (af...@james.freenet.hamilton.on.ca) wrote:
: : : "Tim Behrendsen" wrote:
: : : : Why do I care if a useless program like "Hello World" takes the minimum
: : : : number of bytes? The fact is, 'printf' is capable of a lot more than
: : : : just displaying a text string. This cost is negligable as a percentage
: : : : of a real program.
: Scott Nudds wrote:
: : : Clearly because the problem this "useless program" so clearly
: : : demonstrates is found in virtually every other function that C is used
: : : to compile. It is clear evidence that C optimizes like shit.
: (Will Rose) wrote:
: : The size of the stdio library has always been a known problem, which
: : is why you needn't include it. If I just use read() and write(), I get
: : a Hello, world binary of around 1K, and most of that is the C runtime.
: Even your minimum size of 1K is 30+ times larger than needed.
: (Will Rose) wrote:
: : C compilers
: : optimise pretty well these days, and if you don't include large libraries
: : then you won't get large binaries.
: And as we have seen, this claim is a fiction. C compilers have made
: minor improvements over the decades but any competent individual who has
: looked at their output can tell you, they still optimize like shit.
: Those who claim otherwise have not looked, or are not competent
: enough to know what is and is not optimal.
Actually my numbers are wrong - I forgot to strip the binaries, so
the minimum hello.world is 480 bytes. Looking at the assembler,
there's not much that can be dropped given the program structure;
the runtime just checks for command line options and a hardware FPU,
and a lot of the rest of the code is saving/restoring registers on
function calls.