More easily answered if the original statement had been preserved in context. However in this case if the ES segment has range limits, a segment fault will be triggered. Due to the happy looseness of the term "undefined behavior" no specific action is needed, which is what enables the loosing of nasal demons or launching of missiles.
-- "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
No, it wasn't. Quite possibly the term has no practical meaning, but even if it does, C isn't it. C is at a lower level than most high-level languages, but there's a *much* wider semantic gap between assembly language and C than between C and other HLLs.
I skimmed that article; it doesn't support your argument. The nearest thing in the article is:
It is quite possible to write C code at a low level of abstraction analogous to assembly language; in fact C is sometimes referred to (and not always pejoratively) as "high-level assembly" or "portable assembly".
Calling it assembly doesn't make it assembly.
Show us a definition of the term "assembly language". By "definition", I mean something that unambiguously allows you to determine whether something is an assembly language or not. If you do so, I predict that either (1) your definition won't apply to C, or (2) your definition won't match any common understanding of the term "assembly language".
-- 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.
The reference you give doesn't say that. It says "in fact C is sometimes referred to (and not always pejoratively) as "high-level assembly" or "portable assembly"." When they say "sometimes", they're talking about you, not the rest of the world. Remember that the moon is sometimes said to be made of green cheese.
In fact, from your reference, "but this was onerous since all the code was in assembly language. They decided to use a higher-level portable language so the OS could be ported easily from one computer to another."
Note the use of the phrase "higher-level portable language."
There are better sources, including the original authors.
-- Al Balmer Sun City, AZ
Sorry, that's bullshit.
However, show me a definition of bullshit (by "definition", I mean something that unambiguously allows you to determine whether something is bullshit or not) and I'll readily retract that statement. ;-)
Cheers,
- Alf
-- 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?
According to my newsreader, your first post was at 4:34 am, and your second at 5:30 am. What were you expecting? Do you have this group confused with a chat room?
-- Al Balmer Sun City, AZ
I'm sorry for not being clear:
Wikipedia is not a reference to back up some statement, and in fact it's not a reference of any sort (but let's not go off discussing /that/ again, just trust me: it isn't).
I gave the link as an opportunity for Richard, and now you, to learn some very basic things, and that's why I wrote "e.g.", which means, "for example". Also see the links provided elsethread.
-- 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?
are you in US too?
pheraps in your time, my second post seems to me 12:34am, here in Italy; i think you are in US. near Boston?
If p=s-1 would only cause decrementing of DX (and not effecting ES) and thus wrapping to FFFF, then what would p++ do ? It would be logical to assume that only DX would be affected and incremented by 1, causing wrapping DX back to 0000 and hence ES:DX would have the same representation as the original s and p == s would be true.
Paul
Why, thank you! There aren't any "basic things" in that article which I haven't already learned, most of them decades ago. I'm sure the same is true for Richard and Keith. OTOH, the article could have been a learning experience for you, but apparently it was not.
(Talk about making assumptions!)
I think it's time to drag out an acronym I haven't used for a while - ABIYP.
-- Al Balmer Sun City, AZ
Well my original statement was that C was a glorified assembler. We don't need to stretch the meaning of like to the breaking point.
The point is I can assign an integer value to a pointer. The warning is a nice reminder, but that is all it is. Assemblers allow integers to be used as pointers. Many HLL's never allow this. Can you suggest another HLL that allows simple assignment of integer to pointer? (I recall PL/M, a version of PL/1 for micros from INTEL. It specifically for embedded programming so this was a required feature.)
Irrelevant
You are missing my point. It has nothing to do with whether C generates a diagnostic. And I'll happily accept the cast to be rid of it. Point is I can manipulate memory pointers in C very easily, nearly as easily as I can in assembler.
An assembly programmer has to take on more responsibility. C provides some tools to help. In fact, the casting helps to a small degree. consider writing memcpy() in assembler, C, or other HLL. It is very easy for Assembler and C. In C it may lead to code that has hidden assumptions (the topic here) but the code will have a look very much like assembler. In some HLLs it might not be possible to write a generic memory copy routine.
Let me put it this way. If you are implementing memcpy(), the very fastest, most optimized version might be pure assembler. Next would be a version in C customized for the target platform with close to 100% of the performance of the assembler version. The C version will be easier to maintain than the pure assembler, but to get it that close requires the programmer to think of the consequences of certain programming constructs. Then you'll get a version in some other HLL which might run well, but will be measureably below the performance of the C and assembler versions.
Yes in C I need to consider the significance of pointer types. But this is analogous to assembler opcode options. MOVB -- move a byte MOVW -- move a word MOVL -- move a longword
Actually I'd assign type short to that integer. Good point though. You made me see I picked the wrong argument. Back to the machine with 9bit CHAR. In C the MAX_INT is dependent on the underlying processor and is allowed ro range up to what the hardware can handle, so instead of
32768, you can go up to 131071 Other HLLs do not let that happen. the max int in PASCAL is 32767, even on that same machine. A High level language was supposed to get us away from thinking about the underlying hardware wasn't it?Okay, I found a web page off the PL/I faq page. here's a comment about PL/I' independence from the hardware that speaks directly about dayatypes:
PL/I defines its data types very precisely without regard for any hardware. For example, an "integer" is defined as having a mode of REAL or COMPLEX, base of BINARY or DECIMAL, along with the precision that you require. Therefore, FIXED BINARY(12) declares a binary integer of
12 data bits, whereas FIXED DECIMAL(3) declares a decimal integer of 3 decimal digits. You get precisely what you ask for. The implementers deliver even if the machine has no support for such data type or precision.So I had the syntax wrong (It's been a LONG time since I did PL/I), but the point is the value range is independent of the underlying hardware. In C this is true for the low end. That 6bit byte machine would require extra code from the C compiler to implement 8bit char types. but on a 9bit byte machine C happily lets the programmer get access to that ninth bit, not so in PL/I.
PL/I seems to me better than C in that it reduces the hidden assumptions. So if you need 12bit integers, you get exactly that with an exception generated when you hit the limit, no matter what the underlying hardware can handle.
Ada (yes you're right on the letter case) is similar to C. One reason is that Ada is supposed to be for embedded systems, so it needs the flexibility of open-ended data ranges. But it also does a LOT more type checking than C. I only looked at it years ago, never written any real code in Ada.
But in Ada you could declare type Integer_24 is range -2**23 .. 2**23-1; I don't expect stdint.h has those defined.
Yes, Ada was a poor choice here. It's too close to C in its feature set.
TRUE. But portability alone doesn't free C from the feel of assembler.
16bit 8086 assembler code still worked essentially unchanged on the 386 processor.yes, as I said in another post, it is a question of degree..
I can understand that view, but on the Assembler to HLL scale I still put C closer to assembler. Ada does a lot more for you than C does, AFAIK.
I never said you couldn't. I like C. I have been using it in various projects since the early 80's. It is a great language. I guess I'm just saying you can write better C code knowing its assembler side. Doing that will help keep you aware of some of these gotchas we've been discussing.
I remembered UNIX started on earlir model, but I thought it was a PDP-8. I don't recall a PDP-7. But I thought C came after the initial versions of UNIX.
I'll double check my PDP-11 manual about the increment modes. I would swear they were both. available.
If you approach C with an Assembler proing mindset, you can exploint certain features to your advantage on targetted code. Being aware of that aspect of C can help you avoid some of those things inwriting portable C code.
No, someone with only a HLL view of coding would look at that restriction and say "what the %^&*! Why doesn't this work?" But someone with assembly experience would understand it immediately.
That's it. We just differ on the scale.
I don't have a stron sense of the distances. I guess I would put C about equidistant from both assembler and PASCAL. Hm, maybe someday I will have to come up with a scale for this) FORTH is a good example too. To me FORTH is more like a VM language. But I haven't done any programming in it, so I left it out.
And when you HAVE to write non-portable code, C is a better choice than PASCAL or other HLLs (except maybe Ada).
Great discussion. Thanks for the informative replies. Ed.
Bad guess. Anyway, local time doesn't affect the length of time between the messages.
(Hint - a glance at my sig would have provided a clue as to my whereabouts.)
-- Al Balmer Sun City, AZ
No, sarcasm is not called for or appropriate in this context.
Yes, you should thank me. But you do it like pointing at a very nice car, then saying, "Hey, I'm being sarcastic! That's a car! End sarcasm!". And in case you failed to understand that example, although debating technique is probably off-topic in this group: sarcasm that needs to be marked as such, is not a good way to win rhetorical points.
Didn't seem that way a message or so ago; then you presented the view of a complete ignoramus, and -- now you did it again.
What strikes me about the quotes passage above is... Well... The last paragraph, for example. LOL! ROTFF!
-- 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?
However, it's true that many of us have him/her/it plonked, for previous trolling.
Brian
Nah. Seg faults only happen on access, in that situation. The value of DX can't matter: it isn't part of the "pointer" until an access happens.
It looks as though the AS/400 is the only machine that that particular restriction in the standard is there to support. Yay.
Cheers,
-- Andrew
My call, not yours.
Depends on the audience. With some, one must be explicit.
How so? By stating a fact? One that contradicts your characterization of everyone who disagrees with you?
So you did catch it. Not necessarily unintelligent, just a (what's that word? Oh, yes ...) ignoramus.
I should have quit when you first resorted to insulting those who disagree with you. Bye, now.
-- Al Balmer Sun City, AZ
That's stretching a bit beyond the breaking point: you have yet to state /any/ relevant fact in responses to my postings.
In your first posting responding to my posting, you stated:
they're talking about you, not the rest of the world
which is insulting, and then
Remember that the moon is sometimes said to be made of green cheese.
which is even more insulting.
Not to mention that the logic chain that those sentences were part of, was built on an incorrect premise, which I think you knew, seeing as you now resort to outright lying (below).
Note, I have so far responded to your calculated insults in a restrained manner, and I will continue to restrain myself.
I have not characterized others, for the simple reason that of the three or four or so people responding to my posting, only you tried to win rhetorical points by using personal insults.
In short, that bit about me characterizing everyone who disagrees with me, when I've only characterized you (and rightly so), that's untrue, and that means you're now lying to try to resque yourself.
But you cannot resque yourself from that.
For anyone can sort messages on date+time and see that your comment is a plain and simple lie, even with the most Al-friendly interpretation.
Yep, you're stupid.
My only quibble there is with you: you started off being insulting and off-topic. Be careful what you ask. You sometimes get what you ask for.
-- 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?
And my assertion is that C is not an assembler, glorified or otherwise. I doubt that we're going to come to an agreement on that point.
[...]C (as defined by the current standards) does not allow simple assignment of an integer to a pointer. It specifically states that doing so is a constraint violation. It's just as strongly prohibited as assigning a structure to a floating-point object, or using "
If you're not interested in having this discussion, just say so.
If you think my request was unreasonable, please explain why.
I obviously don't know what you mean by "assembly language". I know (more or less) what *I* mean by "assembly language", and as I understand the term, it simply doesn't apply to C. Since you think it does, explaining what you mean by the term would likely be helpful, at least in establishing just where it is that we disagree.
Or you can keep swearing at me, and I can ignore you.
-- 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.
First: we have now, satisfactorily to me, demonstrated that your request on behalf of "us" for a really clear-cut definition of a vaguely defined part of a term as used in contexts other than in that term, had no bearing whatsoever on anything, other than as emotional rhetoric.
Even just the second word of that question, "us", almost blew up my bs-meter!
So in the great American tradition, I planned to sue you -- or somebody -- but happily the meter is now (seemingly) working again.
Then to your question, which AFAICS has nothing to do with the quoted material:
I don't know what "the" discussion is, except it seems that some people are being offended by having C likened to assembly language. I think that inferiority complex could be an interesting background to various discussions, if we just take pains to introduce that angle, e.g. how C does not (seemingly) hold any advantage as a .NET language, and will similarly lose terrain and become more of a specialist's niche language when other such platforms come about, as they must. But, you want to only discuss how the terminology evolved, or who invented it, if it was? I'm no historian. But, one does not need to be a historian to understand what it means: the meaning can be derived logically.
If you think /my/ like follow-up request was unreasonable, please explain why.
Consider that there is an inherent conflict beween "portable" and traditional meanings of the term "assembly language". Yes, we can emulate one computer on another, Church and Turing showed that, but that isn't a meaningful interpretation of "portable". And we can run virtual machines such as JVM and CLR (or even old UCSD p-code, or LISP...) that are essentially equivalent on all computers, and have a "JVM assembly language" (o/w) that's effectively portable, but we don't call that a portable assembly language -- because it's not the language that's portable, it's the virtual machine that it's a language for. And I could go on listing cases where "portable" isn't a meaningful addition. E.g. saying 80386 assembly is "portable" because it can be used with a Pentium is ridiculous, and I think you already agree to all this.
Something must therefore give, rather radically, if the term "portable assembly" is to be meaningful, if we are to make sense of what someone means when he or she cries "portable assembly!". And since the aim then is to keep some meaning for "portability", what must give is some of the non-portable details usually associated with an assembly language. Away goes register names, registers as such (but not the concept), source and destination as part of instruction, the whole of interrupt/hardware exception handling (it was different on different processors), i/o instructions, any machine-specific instructions (like interlocked increment, whatever), and so on, and voila, just add syntax to the remains, the little core left behind, and you have C, or PL/M, or SPL, or whatever your to-the-iron "systems language" favorite is.
Or, you can decide that the term isn't meaningful to you, and thus fail to understand (or at least make it seem to others as if you fail to understand) all statements made about portable assembly language.
Ah, that's... OK! OK! I shall not say the word. You know what. ;-)
One reason why that term, "portable assembly", is still practically useful and mentioned here and there, even on the web, is that "systems language" has been watered down so that even original Pascal, a language only useful for learning programming by hand-compiling simple programs, now qualifies as a systems language.
That single reason is IMO enough to keep the term floating around, but ironically it derives its usefulness from not being used very much, and so not already having been watered down to mean nothing at all...
-- 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?
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.