Holiday Game
in [ASM]
|
Prev: Win32 non blocking console input?
Next: hugi compo #29
From: Rod Pemberton on 5 Dec 2008 07:29 <NathanCBaker(a)gmail.com> wrote in message news:694c1760-337d-418c-b0f3-a36df110c357(a)v13g2000yqm.googlegroups.com... > If the issue could have been solved by simply "looking at the aligned > columns" as you suggest, then the grand minds of CompSci wouldn't have > had as much motivation to invent the superior languages that make use > of distinctive end tokens. The same goes for using fingers as you did... Did they forget how to count? Did they have an expectation that fingers or calculators were insufficient to determine the nesting? Did they expect blocks so large that the are virtually indeterminable? If so, wouldn't you want "for" and "endfor" to have numbers appended so they explicitly match? Or, do the "GM of CS" overreachingly attempt to explicitly solve problems that are quite rare and relatively simple to solve? (You claimed you used fingers...) OR... Do those undeserving of the reverence: "grand minds of CompSci," embrace a hidden agenda to push heavily typed (not to be confused with strongly typed) and ineffective languages like COBOL onto unsuspectingly naive CS students primed and ready to unquestioningly embrace their CS masters' "brilliance" without realizing that embracing their liberal and flawed ideology was a total waste of their life until many decades later? > One cannot determine these answers by simply looking at C code > either. Uh, what C haven't you been programming in? These are all answerable in C, at least prior to C99 which may have obfuscated "true" and "false" when they added booleans. For pre-C99 C, "true" and "false" would be a #define VALUE in the code somewhere. > Are you saying that C is a poorly designed language simply > because one must read a manual in order to understand it? I only use one book today as a guide to various peculularities. So, I must ask, "What must you read to understand C?". I can think of a few things you may need to read up on semi-regularly if you're not especially detail oriented, like types of certain parameters, side effects of low use functions, type conversions, etc. I've been programming C so long, I honestly don't recall most of what I had to learn to get here. I remember the basics of 6502: quite important, i.e., integers, addresses, assembly instructions, addressing modes. I remember the basics of logic gates: quite important, e.g., and, or, nor, one and two's complement. I remember some Pascal, but I had already learned structured programming on my own and did so in BASIC regularly. I remember realizing that the C operators either matched algebra or were symbolic for FORTRAN's operators. So, it's a bit like asking an English teacher how many English writing guides or how much Shakespeare they've read. Or, why, despite the fact they are supposed to teach both, they only embrace Greek tragedies as an acceptable form for papers and totally reject Greek comedy... The sicker it is the higher grade, until it's so horrific they become convinced you might (very likely) "go postal." I've read many books on C, a few on C++, a medium number on FORTH, a couple on FORTRAN, etc. for many other languages. > > Besides, I don't program in > > HLA... So, RTFM isn't an acceptable answer. While there are reasons for me > > to ask the questions, there aren't any reasons for me to RTFM. But, those > > who did RTFM, like you, and he who wrote TFM should know the answers. > > > > I cannot believe that any of those answers are un-known. Oh, I'm sure they are known - just not by me - which was why I asked. Hopefully, they are known by you since you wrote the program. But, you are avoiding answering these basic questions. They should definately be known by Randall. > Surely, if a > manual page has been inadvertently deleted, or if Randy has forgotten > to document some obscure point, then it is obvious that disassembly > should provide some enlightenment. That requires one who doesn't use HLA to do even more with HLA, i.e., download it, compile with it, disassemble it (probably using another package like NASM), when the package likely comes with the manual that I'm not interested in reading. Rod Pemberton
From: Herbert Kleebauer on 5 Dec 2008 04:31 NathanCBaker(a)gmail.com wrote: > > > The 'mov( 0 ... " is self-commenting. > > > > > > Why should this be better readable than > > > > > > sub.l r0,r0 > > > > eor.l r0,r0 > > > > > This requires: > > > > > sub.l r0,r0 ; store 0 in r0, this is not declaring a sub-routine. > > > eor.l r0,r0 ; store 0 in r0, this is not a tail-less donkey. > > > > If it isn't obvious that e.g. "5-5" is the same as "0" then it's > > better to not do assembly programming. > > > > In Algebra, 'func( x ) = func( x ) - func( x )' does not make any > sense. ???? Why does g(x) = f1(x) - f2(x) doesn't make any sense if function f1 is the same as dunction f2? > But 'func( x ) = 0' does. A function f(x) which is constant zero makes the same sense as the function f(x) = sin(x) - sin (2*pi+x) But what have function to do whith subtracting two integer numbers "sub.l r0,r0" ? > So, your program avoids calling "library code" by calling the superior > "Library code" instead?? No, it avoids calling program code which I also could write myself as part of my program. If you want to write a program which is a sequence of library calls, then there is absolutely no reason to make this calls in assembly. And with HLA it's even more worse: > rand.randomize(); > player.show(); > mov( true, edx ); If it would be at least call rand.randomize call player.show move true,edx then it would be clear what are library calls and what are cpu instructions.
From: robertwessel2 on 5 Dec 2008 05:44 On Dec 5, 6:29 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > <robertwess...(a)yahoo.com> wrote in message > > news:00b99e16-304e-4ecc-a6e2-d193025dd4de(a)q9g2000yqc.googlegroups.com... > On Dec 4, 4:00 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > > > Ok, I didn't look this all up again. It's from memory... IIRC, the C > > > standard requires a "C char" must be large enough to represent the > entire > > > character set. It must be at least the size of the minimum addressable > > > number of bits, which, IIRC, is called a "C byte". If a "C byte" is too > > > small to represent the entire character set, a "C char" can also be > multiple > > > "C bytes". However, minimum sizes of types are declared elsewhere, with > 8 > > > bits, IIRC, being the smallest size for a "C char". > > > A C char and byte are the same size, > > False. > > > and the terms are largely > > synonymous. > > True. But, that's because microprocessors dominated. And, they > "defacto-ly" represent a byte as 8-bits which fits well with C byte and C > char. > > > There is no smaller unit of addressable storage in C than > > a char, and chars must be at least 8 bits, > > True. > > > and must be able to store > > at least the values 0-255 in unsigned format, and -127 to +127 in > > signed form. > > Not sure. Don't care. IMO, the signed and unsigned values are not > relevant. As stated, it must be 8-bits or more and large enough to > represent the entire character set. I.e., if the character set is 0-127, > the 8-bits only need to represent 7-bits of information: 0-127. I.e., if > the character set is 0 to 65536 or -32768 to 32768, then the C char must be > at least 16-bits, even though a C byte may only be 8-bits. > > > If the native "byte" of an implementation is smaller than that, a > > conforming implementation will have to use multiples of that (or some > > other scheme) to implement a C char of at least the minimum size, > > True. While I believe the second para is true, as you've stated the first > paragraph, it presents a problem with the second paragraph, specifically > with my "False" response above. > > I.e., there is a contradiction: > > > A C char and byte are the same size, > > In the context of para #2, a C char and a C byte aren't the same size. As > you stated, a C char will be some multiple of C bytes. E.g., if the > smallest native addressable unit is 4-bits, that's a C byte. And a C char > must be at least 8-bits, therefore it's at least two C bytes. E.g., if the > smallest native addressable unit is 9-bits, that's a C byte. And a C char > must be at least 8-bits, therefore it's one C byte of 9-bits. > > > but > > there will be no way to address that smaller type without some sort of > > language extension. > > As you stated, there is no need to: > > > There is no smaller unit of addressable storage in C than > > a char > > The important part is the "in C" clarification... Quoting from the C99 standard: "3.6: byte: addressable unit of data storage large enough to hold any member of the basic character set of the execution environment. NOTE 1: It is possible to express the address of each individual byte of an object uniquely." "3.7.1: character - single-byte character <C> bit representation that fits in a byte" The C89 standard says: "3.5: character - A bit representation that fits in a byte. The representation of each member of the source and execution environments shall fit in a byte" IOW, as far as C is concerned, the thing called a byte and a char are essentially the same thing. That is reinforced in a number of other places in either version of the standard. For example in 6.2.6.1 (C99): "Values stored in non-bit-field objects of any other object type consist of n * CHAR_BIT bits, where n is the size of an object of that type, in bytes. The value may be copied into an object of type unsigned char [n] (e.g., by memcpy); the resulting set of bytes is called the object representation of the value." Which clearly requires the equivalence of bytes and chars. It clearly says that N bytes can be stored in N (unsigned) chars. 5.2.4.2.1 of C99 ("Sizes of integer type" ) says in the definition of CHAR_BIT, "number of bits for smallest object that is not a bit-field (byte)". And further specified that CHAR_BIT be at least 8. Footnote 40 of 6.2.6.1 (C99): "A byte contains CHAR_BIT bits." Which happens to be exactly the same number of bit a char contains. There are numerous other such statements. There is no smaller unit of addressability in C than a char. Which is the same as a byte. Your statement "if the smallest native addressable unit is 4-bits, that's a C byte. And a C char must be at least 8-bits, therefore it's at least two C bytes." is flatly wrong. There is not, without a non- standard extension, any addressability to anything smaller than a char. And C bytes may not be 4 bits. There is no type "byte" in C, it exists in the C mostly to distinguish the notion of the physically stored data in memory from the logical type char. That hardware bytes (for lack of a better term for the smallest addressable unit of storage) are commonly 8 bits these days is wholly irrelevant. Hardware bytes, whatever those may be, are *not* addressed by the C standard. If whatever the hardware likes to treats as the minimal addressable unit does not meet the C (and implementation) requirement of a byte (or the identical requirements for a char), the implementation must manage some mapping. And those hardware bytes might well be too small *or* too large. A machine with four bit hardware bytes wanting to implement 8 bit C bytes, would need to deal with the hardware bytes as pairs. A word addressed machine with 32 bit words (or hardware bytes), would need to generate code to pack and unpack four C chars (again assuming we wanted the implementation to have 8 bit C chars), from a single word as needed. All of which is irrelevant, except to implementation. If you wanted to implement a system with 16 bit C bytes (and thus 16 bit C chars), on a 8-bit-byte addressed machine, the compiler will have to generate code so that all char accesses address a pair of 8- bit hardware bytes. And the smallest addressable unit in the C program will be that 16 bit C char. Nor is your assertion that hardware with a 9-bit hardware byte requires a 9-bit C byte and char true. While that might well make for a convenient implementation on the machine, there is no reason that the implementation might not expose 8 bit C bytes and chars, and synthesize those out of the underlying 9-bit hardware bytes. It could, for example, store 9 C chars in 8 hardware bytes, or store one C char per hardware byte, and ignore one bit of each hardware byte. In fact, you might be tempted to do such a thing if you wanted to port much existing C code to your 9-bit-byte machine, simply because so much code will break if CHAR_BIT is not 8. Nor is the range of signed and unsigned values that can be stored in a C char irrelevant. A char is an integer type, and must meet certain requirements. It has the additional requirement of needing to be able to store all of the characters in the extended character set for the implementation, and that all members of the basic character set be positive when stored in a char (which for 8-bit chars either requires that all characters in the basic set have values less than 128, or that char is unsigned).
From: Phil Carmody on 5 Dec 2008 09:50 "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> writes: > IOW, as far as C is concerned, the thing called a byte and a char are > essentially the same thing. Yup. The standard doesn't pretend that what it calls a byte is what the underlying architecture calls a byte. There's quite a bit of leeway as to how bytes/chars are implemented, because pointers are kept similarly abstract. Early Alphas simply didn't have byte addressing, for example, so there's precedent for consecutive C bytes not having consecutive machine-addressible addresses (by virtue of them not being addressible). Quite what bizarrities might be possible yet meeting the requirements in the standard on on 24-bit DSPs, or 36-bit-la-la-land, would probably scare most only-ever- programmed-on-an-x86 types. Phil -- I tried the Vista speech recognition by running the tutorial. I was amazed, it was awesome, recognised every word I said. Then I said the wrong word ... and it typed the right one. It was actually just detecting a sound and printing the expected word! -- pbhj on /.
From: NathanCBaker on 5 Dec 2008 13:51
On Dec 5, 7:29 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > <NathanCBa...(a)gmail.com> wrote in message > > news:694c1760-337d-418c-b0f3-a36df110c357(a)v13g2000yqm.googlegroups.com... > > > If the issue could have been solved by simply "looking at the aligned > > columns" as you suggest, then the grand minds of CompSci wouldn't have > > had as much motivation to invent the superior languages that make use > > of distinctive end tokens. > > The same goes for using fingers as you did... Did they forget how to count? > Perhaps they didn't realize that a well-designed code editor { one that shows a colored dotted line from the opening brace to the closing one, no matter how many screen-pages apart the two are } could solve the problem? > Did they have an expectation that fingers or calculators were insufficient > to determine the nesting? Did they expect blocks so large that the are > virtually indeterminable? If so, wouldn't you want "for" and "endfor" to > have numbers appended so they explicitly match? Or, do the "GM of CS" > overreachingly attempt to explicitly solve problems that are quite rare and > relatively simple to solve? (You claimed you used fingers...) OR... Do > those undeserving of the reverence: "grand minds of CompSci," embrace a > hidden agenda to push heavily typed (not to be confused with strongly typed) > and ineffective languages like COBOL onto unsuspectingly naive CS students > primed and ready to unquestioningly embrace their CS masters' "brilliance" > without realizing that embracing their liberal and flawed ideology was a > total waste of their life until many decades later? > Oh noes! Conspiracy Theory time! :) > > One cannot determine these answers by simply looking at C code > > either. > > Uh, what C haven't you been programming in? These are all answerable in C, > at least prior to C99 which may have obfuscated "true" and "false" when they > added booleans. For pre-C99 C, "true" and "false" would be a #define VALUE > in the code somewhere. > I am still not convinced that C is an assembly language. > > Are you saying that C is a poorly designed language simply > > because one must read a manual in order to understand it? > > I only use one book today as a guide to various peculularities. So, I must > ask, "What must you read to understand C?". I can think of a few things you > may need to read up on semi-regularly if you're not especially detail > oriented, like types of certain parameters, side effects of low use > functions, type conversions, etc. > > I've been programming C so long, I honestly don't recall most of what I had > to learn to get here. I remember the basics of 6502: quite important, i.e., > integers, addresses, assembly instructions, addressing modes. I remember > the basics of logic gates: quite important, e.g., and, or, nor, one and > two's complement. I remember some Pascal, but I had already learned > structured programming on my own and did so in BASIC regularly. I remember > realizing that the C operators either matched algebra or were symbolic for > FORTRAN's operators. So, it's a bit like asking an English teacher how many > English writing guides or how much Shakespeare they've read. Or, why, > despite the fact they are supposed to teach both, they only embrace Greek > tragedies as an acceptable form for papers and totally reject Greek > comedy... The sicker it is the higher grade, until it's so horrific they > become convinced you might (very likely) "go postal." I've read many books > on C, a few on C++, a medium number on FORTH, a couple on FORTRAN, etc. for > many other languages. > So, you are saying that C is a poorly designed language? > > > > > Besides, I don't program in > > > HLA... So, RTFM isn't an acceptable answer. While there are reasons for > me > > > to ask the questions, there aren't any reasons for me to RTFM. But, > those > > > who did RTFM, like you, and he who wrote TFM should know the answers. > > > I cannot believe that any of those answers are un-known. > > Oh, I'm sure they are known - just not by me - which was why I asked. > Hopefully, they are known by you since you wrote the program. But, you are > avoiding answering these basic questions. They should definately be known > by Randall. > I answered your questions in an earlier post. What part of it do you want me to clarify? Nathan. |