Re using BREAK in 'C'
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 | Next > |
 |
Re: [TECH] language - was [PIC] using BREAK in 'C'
by sergio masci-2
::
Rate this Message:
On Sat, 25 Jul 2009, Gerhard Fiedler wrote: > Olin Lathrop wrote: > > > I'm pretty sure that if I had been required to type END or something > > more verbose than "}", the mistake would never have happened or I > > would have noticed it much quicker. > > You can define preprocessor macros and use Begin and End instead of { > and }. Noooooooooooooooooooooooooo......... </dispair> I've seen this done and had to live with it for a while. Really really REALLY bad idea. Consider, defined are: BEGIN { END { IF if ( THEN ) { ELSE } else { ENDIF } WHILE while ( DO ) { DONE } you find a piece of code that is several pages long and looks like: IF ... THEN ... // several pages of code here DONE What's the intent of this code? Was it supposed to be a loop or a conditional? Did the original programmer have a brain fart while writing this, start out writing a conditional, changed his mind part way through and finished as if it were a loop (but forgot to go back and change the IF to a WHILE). Isn't the compiler supposed to give you a kick and force you to clarify this? Friendly Regards Sergio Masci -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by sergio masci-2
::
Rate this Message:
On Sat, 25 Jul 2009, Gerhard Fiedler wrote: > sergio masci wrote: > > >>> You seem to want intrinsic functions that you can also write > >>> yourself if you want to. > >> > >> No. I've written this already. Conclusions based on this have > >> nothing to do with what I wrote. > > > > Yes Gerhard as Olin says you do seem to want intrinsic functions that > > you can also write yourself if you want to. > > > > This is not a bad thing, just incredibly difficult to achive > > efficiently. By which I mean have a modern PC capable of generating > > an executable from such a compiler in an acceptable time. > > > > By definition, intrinsic means that the compiler understands what > > these functions do and how they do it. > > I already wrote a few times that what I'm thinking are functions for > which the compiler writer knows what they do, but not necessarily how > they do it (that is, they may be implemented in a library, not > necessarily by the compiler)? Yes I understand this (and I have gone to great pains to ensure that I understand exactly what you mean). What you are describing *** ARE *** intrinsic functions because they become part of the language and are fundamental to the operation of the compiler. How they are stored on the computer if not important, how information is extracted from them to generate code is not important. The fact is the compiler knows about them and their special requirements to the point where it is able understand the interaction between these functions (you have made this a requirement). All this said - they are now intrinsic. > > > But this would still be intrinsic to the compiler because the compiler > > has a preconceived idea of what the function does and the actual source > > code for the function would not change this idea. > > Calling a function with a standard interface ("preconceived idea of what > it does") and an implementation in a library for which source code is > available "intrinsic" is against every common use of this word. No it is not. What you have done is taken an ordinary library and made it intrinsic while keeping the actual source code of the library accessable from outside the compiler. Kind of like intrinsic functions with "hooks". May I remaind you that you yourself suggested that the compiler writer "knows" what these library functions do because they themselves are defined in a standard and that this information could be used by the compiler to understand the interaction between these functions - hence "preconceived idea of what it does" (this was not some kind of derogetory remark aimed at you it was simply a statement of fact :) Part of me like this idea (alternate personality 17 :) and I'd love to take a few years to go away and play with it - but you are talking about intrinsic!!!! > Including against your own... you already said that you don't consider > the C++ function std::list::insert an intrinsic function. But it's this > type of function that I'm talking about. Yes I have already said that I do not consider 'std::list::insert' intrinsic and I still don't. The reason is simple, there is no specialised code built into the C++ compiler that looks out for *** AND *** treats 'std::list::insert' in a special way. Friendly Regards Sergio Masci -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
|
|
|
|
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Gerhard Fiedler
::
Rate this Message:
sergio masci wrote:
>> Including against your own... you already said that you don't >> consider the C++ function std::list::insert an intrinsic function. >> But it's this type of function that I'm talking about. > > Yes I have already said that I do not consider 'std::list::insert' > intrinsic and I still don't. The reason is simple, there is no > specialised code built into the C++ compiler that looks out for *** > AND *** treats 'std::list::insert' in a special way. Maybe there isn't (do you know for sure?), but there could be (given that the meaning 'std::list::insert' is just as defined by the language standard as the meaning of 'else'). Is there any reason why there couldn't be? I'm still talking about your first example, replacing a 'delete' followed by an 'insert' with a 'replace' (given that all three a suitably defined). IMO, if this is a correct replacement, the compiler can make it, independently whether the three are implemented in a standard library or by the compiler. IMO, you haven't yet brought up a good reason why not. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Gerhard Fiedler
::
Rate this Message:
sergio masci wrote:
>> Olin Lathrop wrote: >> >>> I'm pretty sure that if I had been required to type END or something >>> more verbose than "}", the mistake would never have happened or I >>> would have noticed it much quicker. >> >> You can define preprocessor macros and use Begin and End instead of >> { and }. > > Noooooooooooooooooooooooooo......... </dispair> I didn't say that I'd find it a good idea :) > I've seen this done and had to live with it for a while. > Really really REALLY bad idea. > > Consider, defined are: > > BEGIN { > END { > > IF if ( > THEN ) { > ELSE } else { > ENDIF } > > WHILE while ( > DO ) { > DONE } > > you find a piece of code that is several pages long and looks like: > > IF ... THEN > > ... // several pages of code here > > DONE > > What's the intent of this code? Was it supposed to be a loop or a > conditional? Did the original programmer have a brain fart while > writing this, start out writing a conditional, changed his mind part > way through and finished as if it were a loop (but forgot to go back > and change the IF to a WHILE). Isn't the compiler supposed to give > you a kick and force you to clarify this? Ah... this wouldn't have happened with Pascal-style redefinitions. Pascal, like C, treats all blocks alike, no matter the statement they're associated with. In neither language you have a means to distinguish them, like you do in BASIC. I haven't programmed enough with BASIC to be able to say whether I'd like it. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Gerhard Fiedler
::
Rate this Message:
Olin Lathrop wrote:
>> What "not necessarily"? Sometimes, it seems you don't really try to >> understand and go against, just because... :) > > I was disagreeing with the part that it's easier for the programmer > to get a verbose syntax wrong, as I illustrated with a actual case. I can see your point, but being engineer, I don't really think any of us knows this without having made some real measurements. My experience is that it's very very rare to get the braces wrong -- so rare that it's a non-issue in discussing its virtues. There are other, much more influential problems with any language. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Gerhard Fiedler
::
Rate this Message:
Olin Lathrop wrote:
>> I think it's been decades that I had a bug in a C program (a bug, not >> a "doesn't compile" error) that was due to an incorrectly typed >> parenthesis. > > Yes, but compile errors still waste time, as was the case in my > example. I see that, but IME it is negligible. YMMV, of course... after all, it's not for nothing that you wrote a Pascal-to-C compiler :) >> People are liable to make more typos when they have to type more. > > I guess this is the fundamental disagreement. I think I'm less > likely to get "end" wrong than "}". By getting wrong I include the > immediate automatic checking the brain does of the key strokes and > you visually do by watching the screen as you type. I consider these > immediate processes to be part of the act of typing, with a typo > being a error that survives this process. See my other post about > this automatic checking. As I responded there, I can see that, but I still think it's negligible. OTOH, I almost never type "}" -- I have my editor do this. Whenever I type "{", it inserts the next line, indents it, puts the cursor there, and inserts the closing brace a line below. Whenever I want to wrap a sequence of lines into braces, I mark it, type "{" and the editor does its job (adding "{" at the start, "}" at the end, indenting the marked lines). If I type a "}" where I meant a "{", I see this immediately very clearly: firstly, because the expected expansion didn't follow, and secondly because if there's now an imbalance in the braces, the not matched ones are highlighted. To end the discussion (going back to the beginning of C and Pascal :) whether braces or begin/end are better, compilers (both C and Pascal) could come with a switch that allows the user to choose :) Of course, Sergio would say that both languages got it wrong... >> I didn't quite oppose what Olin said. With the exception of a rather >> unimportant side-issue, I thought that what I wrote originally was >> pretty much the same as what Olin wrote, even though looked at from >> a slightly different angle. The only thing I really opposed was >> Olin's opposition (as expressed in the "not necessarily"). > > Now I'm really confused ;-) This is a good thing, occasionally :) Basically, I think the difference stems from two "boundaries" that are different: "I consider these immediate processes to be part of the act of typing ..." I considered "typing" only the typing. "... with a typo being a error that survives this process." I considered the really problematic typo the one that survives both this process and the compiler checks. > By the way, my translator is available via free download. It is > included in the full runtime release available at > http://www.embedinc.com/pic/dload.htm. The source code is open and > included in the "host source code and everything" release on the same > page. I've said this before, and I think it's worth repeating. Besides all our differences, I admire the effort you put into your tools -- and the fact that you make much of that publicly available. And if more people who use C put a similar effort in their environment, much of what gives C the bad rep wouldn't be there. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by sergio masci-2
::
Rate this Message:
On Fri, 24 Jul 2009, Gerhard Fiedler wrote: > sergio masci wrote: > > >> I suspect that in many compilers (3) and (2) end up (as an > >> intermediate representation) in something that's equivalent to (1). > >> But even if not, it shouldn't be too difficult to make all three end > >> up in the same, whatever the compiler's internal representation of > >> this statement is. > > > > Ok so I write a seperate parser for all three and internally they all > > produce: > > > > if_statement > > .. expr > > .. .. lt > > .. .. .. x > > .. .. .. 0 > > .. statement > > .. .. assign > > .. .. .. y > > .. .. .. 0 > > .. statement > > .. .. assign > > .. .. .. y > > .. .. .. x > > > > So what advantage does this give me? > > I don't know, but if you do it, you probably know :) Seriously, I don't > understand the question in this context. Ok, I understand now, you're talking about going backwards (everything towards the type (1) syntax) whereas I was saying something else - see below. > > > If instead of the keyword 'if' I used a function 'xyz' thus: > > > > xyz( lt(x, 0), assign(y, 0), assign(y, x) ) > > > > my parsers would all now produce: > > > > expr > > .. func > > .. .. xyz > > .. .. expr > > .. .. .. lt > > .. .. .. .. x > > .. .. .. .. 0 > > .. .. expr > > .. .. .. assign > > .. .. .. .. y > > .. .. .. .. 0 > > .. .. expr > > .. .. .. assign > > .. .. .. .. y > > .. .. .. .. x > > > > Internally the compiler has different sections that deal with > > generating code for 'if_statment' trees, 'statement' trees and 'expr' > > trees. > > > > How would you propose that I treat 'xyz' differently while parsing > > and how would you add a specific code generator for the now special > > 'xyz' (you need to describe all this somehow)? > > 'if' is a special statement/construct/function, defined in the language > standard. 'xyz' is not. Therefore, the compiler can have (and generally > has) special code to generate 'if' more efficiently than a function > call. > > Compared to the original issue -- lists --, 'if' is much more simple, > and the function call overhead here is important and more than the > actual functionality typically would be. That's why it generally makes > sense to implement such a construct directly, avoiding the function call > overhead. But it's not just the function call overhead that's important here. If we were to implement the 'if' statement as a function the calling protocol would be completely different to that of a normal function regardless of any special optimisations. In the 'if' statement, either the 'true' or 'false' statement is executed only *** AFTER *** the 'if' condition is evaluated. In the 'if' function, the condition and both the 'true' and 'false' statements (all 3 parameters of the 'if' function) are evaluated before the 'if' function is called. Trying to say that you can achine the same functionality by extending the language using functions as you can by adding special keywords does not hold. You'd have to say "some functions are called like, some are called like that, some are called in bizzaro mode N etc etc etc..." The whole thing would become a mess and you've been forced to change the way the language works anyway :) I am trying to show that internally there is a fundamental difference between the way statements are parsed and code is generated for them and functions are parsed and code is generated for them. Just because you parse both and generate trees for both it doesn't mean that the trees are the same. Ok, so I'll go along with you on this and I'll trap certain functions in my 'new' compiler so that they give you the result you want (delayed evaluation of parameters). But can you not see that the amount of work going into the compiler proper (by the compiler writer) is huge. The language looks like it's being extended by adding functions but these functions have a large component buried inside the compiler. So these functions (in the /standard/ library) apart from having the illusion of being external to the compiler are now fundamental to it and could cause the compiler to generate bad code if they are touched. The only thing I can see that you might gain from this is better optimisation of old code. > > I'm not a compiler specialist, but it could be that 'avoiding the > function call overhead' is a premature optimization, and that a later, > lower-level optimization could result in just this. In any case, since > 'if' is defined in the language standard, there's nothing that would > prevent a compiler writer to implement it in the compiler. Yes but the point isn't about making the 'if' function behave like an 'if' statement it's about how do make other functions also behave in a special way without doing a lot of work in the compiler to treat each function as a special case. If you're going to do all this extra work to the compiler don't kid yourself that the /standard/ library is actually helping the compiler writer - it isn't. The /standard/ library only came into being to help the user get around shortcomings in the language and it's only helping the compiler writer if he/she doesn't need to do anything special with it. > > > the 'if_statement' code generator knows that it might have either one > > or two statements following the condition expression. It also knows > > that if the condition expression evaluates to a compile time constant > > that it can discard either the 'true' or 'false' statements. It also > > needs to interact with the code generator for the condition > > expression to allow that generator to produce efficient optimised > > code jumps to the 'true' or 'false' statements (think of early out > > logical expressions involving '&&' and '||'). Consider the difference > > between "if (cond)..." and "X=cond" > > Yes. This all is pretty much C. I thought we weren't really talking > about any specific languages, but about 'implemented in the compiler' > versus 'implemented in a library'. I'm not talking specificaly about C that was just an example so people could relate. Other languages provide early out logical expressions and the ability to assign the result of a condition to a variable. It wouldn't have helped much if I'd written the example in ALGOL. So I'm not pointing the finger at C and saying "see C is bad", I'm saying "look when you evaluate a logical expression there's more to it than just a simple is 'x==y' and you need to be able to cope with all kinds of nasty stuff" > > The 'if' statement implementation is so short that going through a > general-purpose function call convention would blow up the code > tremendously. But: > 1) Nobody says that the compiler writer /has/ to do this. The 'if' > statement is defined in the language standard, and the compiler writer > can choose to implement it directly in the compiler. > 2) Even if the compiler writer chooses to implement it as function call, > I think it is possible that a lower-level optimization detects the > inefficiencies and successfully optimizes the function call away > (remember that I considered that the function is available as source), > reaching the same code as if implemented directly. I really don't think you would be able to have an 'if' function as source. How would you describe the function to the compiler if you have no built-in conditional statement? Would you resort to assembler? How would you end up optimising this? Would your compiler need a built-in simulator to be able to run the code internally? I mean if you have a cross compiler that runs on a PC and it generates code for a PIC would you need a PIC simulator inside your compiler to be able to execute the assembler for the 'if' function? > > >> So, yes, I think for a compiler these three could be identical. I > >> don't see that a compiler could derive any information from any of > >> them that it couldn't derive from the other two. > > > > Actually it can. Consider a long complex program made up purely of > > functions as in (1). What happens with a misplaced comma or > > parenthesis? > > That's a feature of that specific syntax, not a difference whether the > 'if' function is implemented in the compiler or in a library. We didn't > discuss the various merits of the different syntaxes (sp ?? :) > > > The verbose syntax lets the compiler catch silly mistakes. > > Of course. The more redundant (that is, verbose) the syntax is, the > easier it is both for the programmer to get something wrong and for the > compiler to catch when something is wrong. But we didn't discuss the > merits of different syntaxes, we discussed merits of 'implemented in the > compiler' versus 'implemented in a standard library'. But one of the points I've been making all along is having the compiler identify errors. > > >> Provided, of course, that the functions used in (1) are just as > >> defined as the operators and statements used in (2) and (3). > > > > Ok so I'll give you that, all the functions are defined in exactly > > the same way in (1) as they are in (2) and (3). But what are we going > > to do about the vast number of functions defined in the /standard/ > > library? > > I don't understand the question. I didn't mean to suggest that all > functions need to have an equivalent in the forms (2) or (3), but rather > the other way round, that typically constructs of the forms (2) or (3) > have an equivalent function call syntax that does the same > (functionally, not necessarily in terms of typing or user-friendliness). > Ok so if I understand you correctly what you are saying is "if any program written in syntax "X" can be converted to the equivalent as if it had actually been written in syntax (1) (the function call syntax), then the function call syntax is powerful enough to do anything that a much more complex syntax would allow". This is what you are saying right? Ok assuming you are. The problem with this is the intelligence needed within the compiler to understand the intent of the programmer. This is what I've been pointing at all along. Ok so I haven't gotten my point across. Look, it's like this: any (correct) high level language program can be converted by a compiler into a machine code executable (by definition that's what compilers do), but taking an executable and going the other (using a program to convert it to high level language source) is very difficult. The higher the level of the language you want the "de-compiler" to convert to the harder it gets. The ultimate would be to say "this decompiler explains in common english what this executable does (a documentor?)". If you use a higher level language than C (with built-in STRINGS, LISTS, STACKS, MULTITASKING etc) you are starting from higher level and therefor impart greater "intent" into your program. It's like me saying "turn on lamp commected to relay 6" and the compiler saying "wait a minute you don't have a lamp on relay 6 you have freezer connected to that relay". As opposed to saying "PORTB |= 1 << 3". As I tried to show in an earlier post (where I showed many different ways to append the ascii representation of a number to a string), trying to understand the intent of a programmer by looking at lots of function calls is *** VERY *** difficult. > > >>> AND because the compiler should be able to "understand" functions as > >>> easily as other language statements that it is a convenient way to > >>> extend the language. > >> > >> Yes, extend or customize. That's approximately the C++ standard > >> library way. > > > > But the C++ way is horrible! You have CLASS upon CLASS upon CLASS. If > > you want to write a modest program you end up so deep in 'standard' > > classes and templates that it gets very hard to see the wood for the > > trees. > > This is not about a specific implementation of the principle, this is > about the principle. You always bring in C, despite (or because?) we > already agreed that the C way is pretty much horrible. And we probably > can agree that the BASIC way is horrible, too -- some exceptions > notwithstanding :) > > > This nonsense that user classes should be written in such a way as to > > have special methods that the standard libraries expect (things like > > iterators) so that the items in a container can be accessed. The > > programmer shouldn't need to know about all this. He should be able > > to just say (e.g.) > > > > for all items in list FRED do > > > > *.x = $.x + 1 > > done > > I don't really understand this. This is probably your syntax, and quite > familiar to you, but I don't think a majority of list readers here would > know what this does. In any case, I don't. No, this is not familiar to me at all. I made it up on the spur of the moment. It propbably doesn't make sense because *.x = $.x + 1 should read $.x = $.x + 1 :-) > > Anyway, for what it's worth, and independently of the issue we're > discussing (compiler-built-in vs standard-library-implemented), my C++ > code looks similar: > > BOOST_FOREACH( item i, FRED ) { > ++i.x; > } There you go then, you could have had a reasonable go at understanding what I wrote :) > > (If this is what your code does... since I don't know what it does, I > can't really tell, but it probably is trivial to correct it if it's > doing something different. And I don't generally use identifiers like > FRED for lists in C++, but that's only a style question.) > > But again, this is not a discussion of C++ style syntax versus BASIC > style syntax (yet :) -- and I don't see anything particularly > advantageous about the C++ style syntax. But all of C++'s list handling > is implemented in libraries -- and that's the issue. > > (I used here an element from the Boost library. It's not a standard > library, but it could be one. Whether or not a given library is a > standard library is just a matter of definition, and not of principle.) You keep refering back to BASIC. Do you think I'm pushing BASIC here? I'm thinking about other things here like SQL, COBOL, ALGOL ICON (you should really look at ICON - lovely language, lots of built in types). Friendly Regards Sergio Masci -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Wouter van Ooijen
::
Rate this Message:
> C30 is like this as well. It knows there is a syntax error in that it has
> reached something without finding a closing bracket, why does it need to use > a catch-all error message??? - because the C syntax is so 'dense' that in most cases there is more than one possible correct continuation (and probably at more than one point in the line) - because in the presence of macro's it makes no sense to indicate the position in the line which caused the error - because of the above most C parser (scanner/tokenizer/lexer) are bottom-up parsers, optimized for speed, not for accurate error reporting - most C compilers seem to think it is more important to continue compiling in order to report more errors than to report errors accurately Back in my Jal days some people critized me for writing my own top-down parser. Like most compilers for Algol-type languages it reported the first error (and only the first), but fairly accurately, bot in position and in the kind of error. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by M.L.-2
::
Rate this Message:
On Sun, Aug 9, 2009 at 5:42 AM, Wouter van Ooijen<wouter@...> wrote:
> Back in my Jal days some people critized me for writing my own top-down > parser. Like most compilers for Algol-type languages it reported the > first error (and only the first), but fairly accurately, bot in position > and in the kind of error. I think I would normally prefer useful error messages rather than the C style where you might get 100 errors because of one missing '}' -- Martin K. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Wouter van Ooijen
::
Rate this Message:
> I think I would normally prefer useful error messages rather than the
> C style where you might get 100 errors because of one missing '}' So do I, and so do all students I ever had. But C (and some other) compilers seem to boost mainly their ability to generate tight code. The computer industry is full of historical artifacts. Why multipass compilers (now almost extinct)? A stone -age compiler could just contain a single pass.. Why make only a single pass over the source input? The stone-ago compiler could contain only a single pass, the input was on cards or magtape or papertape. Why separate compilation? Why a separate linking stage? Why find as many errors as you can in one run? You can probably guess. For the more advanced guessers: why does the ASCII character DEL have the value 0x7F, and what is its exact meaning? -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Jan-Erik Soderholm
::
Rate this Message:
Wouter van Ooijen wrote:
> For the more advanced guessers: why does the ASCII character DEL have > the value 0x7F, and what is its exact meaning? > "All (7) holes punched". -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Wouter van Ooijen
::
Rate this Message:
Jan-Erik Soderholm wrote:
> Wouter van Ooijen wrote: > >> For the more advanced guessers: why does the ASCII character DEL have >> the value 0x7F, and what is its exact meaning? >> > > "All (7) holes punched". If you were a student that would be the problematic type of answer, because it is totally correct, but does not prove that you understand why. Which might mean that the question was badly done... So why is DEL "all holes punched", and what does it mean? For instance, does it mean "delete the previous character", like a backspace? -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Jan-Erik Soderholm
::
Rate this Message:
Wouter van Ooijen wrote: > Jan-Erik Soderholm wrote: >> Wouter van Ooijen wrote: >> >>> For the more advanced guessers: why does the ASCII character DEL have >>> the value 0x7F, and what is its exact meaning? >>> >> "All (7) holes punched". > > If you were a student that would be the problematic type of answer, > because it is totally correct, but does not prove that you understand > why. Which might mean that the question was badly done... No I do not think it was. :-) It was a perfectly valid question. And a good one... :-) > > So why is DEL "all holes punched", and what does it mean? For instance, > does it mean "delete the previous character", like a backspace? > It replaces what was there before in the same position on the punched tape with what could be seen as a "NOP". If my memory doesn't fail me... -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Wouter van Ooijen
::
Rate this Message:
> It replaces what was there before in the same position
> on the punched tape with what could be seen as a "NOP". > If my memory doesn't fail me... Totally correct. (not surprising, knowing that you are a bit older than my average student) -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
RE: [TECH] language - was [PIC] using BREAK in 'C'
by Harry H. Arends
::
Rate this Message:
Found this in a old manual, yes i am 50+ :-)
CORRECTION OF ERRORS Errors on punched tape may be corrected in various ways, depending upon the type of error and when it is noticed. Three correction techniques are explained here. The easiest correction is for an error which is detected immediately after the wrong key has been depressed. In this case, one need only 1. Turn the FEED KNOB on the left side of the punch back one notch. 2. Depress the CODE DELETE lever once. 3. Continue punching by depressing the proper key on the keyboard. If a wrong key is depressed whose tape code is a portion of the desired combination, the operator need only back the tape until the incorrect character is under the punch head, and overpunch it with the proper key. This method is particularly useful when the error is detected after characters have been punched beyond the error. However, it can only be used when the erroneous and correct tape codes are related in the proper way. For example, a "6" can be overpunched on a "O", "2", or "4", but not on "5" since the tape code for 5 has a punch in channel 4 while that for "6" does not. Harry > -----Oorspronkelijk bericht----- > Van: piclist-bounces@... [mailto:piclist-bounces@...] > Namens Wouter van Ooijen > Verzonden: zondag 9 augustus 2009 22:57 > Aan: Microcontroller discussion list - Public. > Onderwerp: Re: [TECH] language - was [PIC] using BREAK in 'C' > > > It replaces what was there before in the same position on > the punched > > tape with what could be seen as a "NOP". > > If my memory doesn't fail me... > > Totally correct. (not surprising, knowing that you are a bit > older than my average student) > > -- > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: www.voti.nl consultancy, > development, PICmicro products docent Hogeschool van Utrecht: > www.voti.nl/hvu > > -- > http://www.piclist.com PIC/SX FAQ & list archive View/change > your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Jan-Erik Soderholm
::
Rate this Message:
Wouter van Ooijen wrote:
>> It replaces what was there before in the same position >> on the punched tape with what could be seen as a "NOP". >> If my memory doesn't fail me... > > Totally correct. (not surprising, knowing that you are a bit older than > my average student) > Probably correct... :-) Found a nice page with the historical background to the lower 32 "control chars" (and DEL) in the ASCII table. http://nemesis.lonestar.org/reference/telecom/codes/ascii.html A *lot* of intersting historical facts about computing in general there ! :-) Enjoy. Jan-Erik. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Alan B. Pearce-2
::
Rate this Message:
>For the more advanced guessers: why does the ASCII character
>DEL have the value 0x7F, and what is its exact meaning? Because you could hand punch a paper tape to the DEL character, whatever it was before. I believe there were metal guides that you could clip on the tape to do this, but don't ever recall seeing one in the flesh. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: [TECH] language - was [PIC] using BREAK in 'C'
by Gerhard Fiedler
::
Rate this Message:
Wouter van Ooijen wrote:
>> C30 is like this as well. It knows there is a syntax error in that it >> has reached something without finding a closing bracket, why does it >> need to use a catch-all error message??? > > - because the C syntax is so 'dense' that in most cases there is more > than one possible correct continuation (and probably at more than one > point in the line) > - because in the presence of macro's it makes no sense to indicate the > position in the line which caused the error > - because of the above most C parser (scanner/tokenizer/lexer) are > bottom-up parsers, optimized for speed, not for accurate error reporting > - most C compilers seem to think it is more important to continue > compiling in order to report more errors than to report errors accurately FWIW, the error messages of the C++ compilers I generally work with point right to the problematic line (or the following line). And when not, the message is specific enough to easily find the line. VC++ for example also can be configured to break on first error. After writing a few days' worth of code and recompiling, I generally get a few syntax errors. These are pretty much really quick fixes; not much thinking involved, due to the good locality and appropriate content of the messages. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
| < Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
