Standard C doesn't accept inline assembly. If some particular compiler does so, it's an extension -- and you might as well think of it as an assembler that also accepts C syntax.
As far as libraries are concerned, most of them aren't part of standard C either -- and they needn't be either implemented in, or called from, C.
-- Keith Thompson (The_Other_Keith) kst-u@mib.org San Diego Supercomputer Center We must do something. This is something. Therefore, we must do this.
Thank you, Captain Pedantic. Is that response to me or the masses of corruptable youths eagerly waiting to sprinkle their code with inline assembly?
If the former, then my point was that in the realm of C dialects, Standard C (ideally) occupies a slowly expanding middle ground. If the latter, then kids, listen to Keith, he's right.
Again, true, but oblique to the point that it is possible to run a fully functional _modern_ system using only code written in C dialects. I don't believe any other language "family" can boast this (for currently available hardware).
Mark F. Haigh snipped-for-privacy@sbcglobal.net
[...]
Was that intended as an insult?
This discussion is cross-posted to three different newsgroups (and it's been interesting in spite of that). I'm reading and writing this in comp.lang.c, where we discuss the C programming language as defined by the standards. The standard specifically allows extensions, and we sometimes discuss the permitted nature of those extensions, but details about particular extensions (such as inline assembly) are considered off-topic.
My comments were intended for anyone who cares to read them.
I have no argument with that point. I was merely making a different point.
-- Keith Thompson (The_Other_Keith) kst-u@mib.org San Diego Supercomputer Center We must do something. This is something. Therefore, we must do this.
Heh, it's just tongue-in-cheek; a little jab. All in good fun.
True, but the topic was really a meta-discussion about where C dialects fit in to the continuum of languages, and where Standard C fits into the continuum of C dialects. It's topical enough for me, and I was hoping to spur some genuine discussion.
Mark F. Haigh snipped-for-privacy@sbcglobal.net
This turns out not to work very well in Real Compilers. The reasons are outlined rather nicely in the GCC documentation:
It is a natural idea to look for a way to give access to the condition code left by the assembler instruction. However, when we attempted to implement this, we found no way to make it work reliably. The problem is that output operands might need reloading, which would result in additional following "store" instructions. On most machines, these instructions would alter the condition code before there was time to test it. This problem doesn't arise for ordinary "test" and "compare" instructions because they don't have any output operands. For reasons similar to those described above, it is not possible to give an assembler instruction access to the condition code left by previous instructions.
(from ).
(You *can* actually capture the condition codes, by doing the operation itself *and* the condition-code-capture all in one single inline __asm__, so that no reloading occurs between the two parts. Getting it right is still fairly tricky. In many cases you are better off just writing the desired routines in assembly, and calling them as ordinary functions from the C code.)
-- In-Real-Life: Chris Torek, Wind River Systems Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://web.torek.net/torek/index.html Reading email is like searching for food in the garbage, thanks to spammers.
In many architectures, there are at least one way around this problem. When an interrupt occurs, at least the processor status word containing the condition codes and the return address are automatically pushed on the stack (and possible some other registers). This usually applies also to software generated traps. The ISR can then copy the condition codes from the stack frame to a safer place.
There are of cause some problems, this would consume one trap instruction, perhaps shareable with some debugger traps. With separate user and kernel spaces, a trap will usually switch to kernel mode, which would require a trap handler to be installed into kernel space and would generate quite a lot of instructions due to mode switching and safe copying between modes.
However, in single address space systems, such as most embedded systems, this should be quite usable.
Paul
That's why I specified a limitation to a comma operator separated statement, or some such. This would give an opportunity to use the equivalent of "push psw" in the generated code, after which the storage can be assigned and filled. By limiting to some specific format we can avoid excessive overhead elsewhere. My mechanism is hardly well thought out, it is only intended to trigger thoughts from others. As I said, blue skying.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
in what i understand (if i understand) the solution for all your problems is to have in the compiler implementation some debug mode for its exe output: the executable when run opens many queues of 20 items: one register all overflow one all memory leak one all memory wrote out of bound ... then at end of program all those queue are print in a log file
if after 10 years of use that program has not problem in its log then it could be compiled without debug queues
*Shrug* If you go about redefining terms to support your delusion that C is a portable assembler, that's your problem, not that of C.
Richard
In article msg writes: > Dik T. Winter wrote: > > the original version of Fortran had a statement with > > which you could tell the compiler what the probability > > was that a branch would be taken or not. > > Sorry I don't have access to our archives at the moment - > we do have materials from 70x and 650 Fortran; to > which machine are you referring? 704, 709, 650?
The FREQUENCY statement from Fortran I (amongst others on the 704).
-- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Happily I haven't followed this debate, so I don't know what you folks, good or not, think "portable assembler" means, nor how you can think a language is a compiler (or whatever).
C was designed as a portable assembly language, the most successful so far, so if the term has any practical meaning, then C is that meaning.
C was designed as a portable assembly language for the purpose of porting Unix (which then had some seven or ten installations, I forget, but one rumor has it there was only one, namely the PDP-7) more easily. That didn't fully remove the need for using actual assembly. But only some small parts still needed to be machine-specific assembly.
You can find more information about the C language at e.g. Wikipedia, .
Hth.
-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
is there someone out there that read this? am i plonked from all NGs?
You would do better to visit which has a number of good links to well-established pages about C. The Wiki page suffers from being modifiable by the clueless.
-- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at above domain (but drop the www, obviously)
I would have said it was designed as a portable language to /replace/ [the use of] assembly language(s) [for a variety of "systems programming" uses].
C looks nothing like any assembly language I've ever seen, which I suppose may just indicate my limited knowledge of assemblers. Calling it "portable assembly language" is an instructive metaphor, but it is just that - a metaphor.
Here are some ways in which C isn't like the assembly languages I've seen:
And some ways it is:
-- Chris "sparqling" Dollin "Who do you serve, and who do you trust?"
Thanks for the prompting.
Thinking about this made me realize that actually accessing condition codes isn't very useful, as an end in itself. Sure, there can be some (like half-carry, perhaps) that might be useful, but if you really needed that, I think that some sort of in-line intrinsic could carry it off. It's not as though it's portable, anyway.
No, the point about condition codes is that they're a means to an end, and C already covers most of those ends with other constructs. Most of the basic condition codes are just there to tell you if some result is zero, or which way a comparison went (whether you consider the arguments signed or unsigned). Ordinary control (if, while, etc) statements handle those nicely.
Lots of embedded processors (ab)use the carry flag as a 1-bit source or result for bit-test operations and rotates, but I've seen plenty of compilers with a good enough library of peep-hole optimizations that will generate the necessary bit-test/branch-on-carry sequence when given the usual if (a & (1
I saw your post. I feel the same way myself, even when my posts show up in google groups. Sometimes people just don't feel the need to respond, I guess...
Cheers,
-- Andrew
In article snipped-for-privacy@invalid.invalid writes: > Alf P. Steinbach said: > > > You can find more information about the C language at e.g. Wikipedia, > > . > > You would do better to visit which has a > number of good links to well-established pages about C. The Wiki page > suffers from being modifiable by the clueless.
But what is on it now is pretty well done.
-- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
I don't think this is what happens. Instead I think DX will wrap to FFFF, and ES will remain unchanged.
-Michael.
I was thinking more about after the fact overflow detection, with statements such as:
if ((a = b + c, ccd = _ccd) & OVFLOBIT) { /* handle overflow, a value is meaningless */ } else { /* all is joy in Mudville */ }
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
... snip ...
You temporarily got off my list due to some changes in newsreader software. At the first sign of more ridiculous obfuscating macros you go right back on it. Meanwhile I am not likely to pay much attention to anything you say.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.