cottrell@nbs-vms.ARPA (COTTRELL, JAMES) (08/30/85)
/* Fiercely I go into battle: > I have always thought that to be a machine dependancy (the value of true and > false). Maybe I'm wrong. But, different machines DO have different ideas > of which is true and false (at the assembler level). And it is simply > a convention. Machines have no concept of truth. They can determine if a condition (equality, greater than, negative, overflow, etc.) exists and then *dynamically* alter the course of their control flow. But no machine I know of has a `branch if true' instruxion. Note I am not talking about the abstraxion a la 68k where an unconditional branch is named `branch if true' & the converse is called `branch if false'. I am talking about a *conditional* `branch if true'. > Still though, #define TRUE (1==1) is very obvious, to the point, correct, > proper, and all sorts of things. And it doesn't require one to know > that detail about C that the convention is ~0 == TRUE and 0 == FALSE. Your attention span must be even shorter than mine. (What were we talking about :-) If you are consistant, ignorance is bliss. But what about fred's code over there, if (p). Hmmmm, now what does that do? > But C gives you all these operators which allow you to define things > machine independantly rather than hardcoding values. Obviously I mean > casts and the sizeof operator. Also arithmetic to pointers. So why not > TRUE and FALSE? > --- David Herron Because who needs them? Integers do quit well, thank you. On to my next victim. > Not really. You could usually safely assume that if someone is defining > true and false, he/she is defining it as above. (if some joker decides > to define false as 29 and true as 53, he should be forced for eternity > to covert 10,000-line APL programs to Fortran! :-) ) Agreed. But it's not 29 & 53 were talking about now is it? Zero & One have certain useful mathematical properties, described below. > I think it is much easier to read things such as: > > done = true; > > than: > > done = 1; How about `done++'. Most variables are initialized to false. It's kinda like reality, nothing can be taken for granted (default false) unless it appears to be true. > Of course, explanatory comments in any case improves readability even > more. > Dan Howell Most definitely. Now for the last one: > To me, the mapping TRUE -> 0 and FALSE -> non-zero doesn't seem obvious, > and I'm sure it isn't to most programmers who ever worked in assembler. > In assembler, one often writes the following (I'm using pseudocode > rather than any particular assembler): > > compare two values > jumpto stuff if zero > > Which is the assembler equivalent of > > if (value1 == value2) > <do stuff> ; I think you've got it backwards. > When I was in high school I was programming TRS-80's in both assembler > and BASIC, and I had lots of trouble remembering whether BASIC > represented truth as zero or -1. No such memory is needed for the > assembler, of course, since comparison is merely done by subtraction (a > compare instruction is usually just a subtract instruction that doesn't > store the result anywhere), so it is obvious what the zero indicator > means. It is not so obvious to me that in C 0 should mean false and 1 > mean true. > -- > Barry Margolin > ARPA: barmar@MIT-Multics > UUCP: ..!genrad!mit-eddie!barmar Ah but it is! Consider the mathematical implications of it! The MAX funxion is just the expression `(A > B) * A + (A < B) * B'. APL, which was designed by a mathematician, uses the exact same concept. The idea of `P implies Q' can be written as `P <= Q'! There have been many different *conventions* used in many languages to represent the *hidden* boolean values, sometimes differing between implementations. I think time will show that APL & C do it the best way. At least the cat's out of the bag & everybody knows what the spots look like. jim cottrell@nbs */ ------
robison@uiucdcsb.Uiuc.ARPA (09/02/85)
> ... But no machine I know of has a `branch if true' instruxion...
The Burroughs 5000/6000/7000 stack machines have both "branch on true" and
"branch on false" instructions which branch if the top-of-stack value is true
or false respectively.rlk@chinet.UUCP (Richard L. Klappal) (09/03/85)
In article <139200010@uiucdcsb> robison@uiucdcsb.Uiuc.ARPA writes: > >> ... But no machine I know of has a `branch if true' instruxion... > > The 808x/Z80 families of microprocessors set the 'zero' flag in 'compare' instructions, and have 'jump if zero', 'jump if non-zero', as well as the corresponding conditional subroutine calls and and conditional returns. They may be too small for you to consider them 'machines', but an awful lot of work gets done on them. -- Richard Klappal UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) -------------------------------------------------------------------------
peter@graffiti.UUCP (Peter da Silva) (09/11/85)
> > ... But no machine I know of has a `branch if true' instruxion...
On the 6809 branch always is implemented as branch if true. They also
have a branch if false which acts as a skip. They call it branch never.pdg@ihdev.UUCP (P. D. Guthrie) (09/13/85)
> > > ... But no machine I know of has a `branch if true' instruxion... > > On the 6809 branch always is implemented as branch if true. They also > have a branch if false which acts as a skip. They call it branch never. *** Oh Line eater, line eater, wherefor art thou? *** On a Dec-20, you have a huge number of strange instructions, including : (no flames if I don't remember correctly -- it's been years) skipn : skip never jumpn : jump never skipa : skip always jumpa : jump always skip : skip jump : jump I don't believe that there is any difference between skipa and skip and also between jumpa and jump, but the extra forms are kept in to make a complete instruction set. By the way, this beastie also has a 36 bit word!! What does this discussion have to do with net.lang.c anyway? Paul Guthrie. Any opinions expresses herein (whether right or wrong) have been generated by the `babble' program.
johnl@ima.UUCP (09/17/85)
/* Written 3:21 pm Sep 13, 1985 by @graffiti@ihdev in ima:net.lang.c */
> On a Dec-20, you have a huge number of strange instructions, including :
Actually it's stranger than you said. Instructions include:
SKIP Don't skip
SKIPA Always skip
JUMP Don't jump
JUMPA Always jump
On the IBM 360/370 series, the branch instrction has a condition mask for
the various states of the condition code. If you set all of the mask bits,
it branches on any possible set of condition bits, i.e. branch if true. If
you set none of the mask bits, it's the no-op instruction, i.e. branch if
false.
This has nothing to do with net.lang.c, followups to net.arch or perhaps
net.games.trivia.
John Levine, ima!johnldaveb@rtech.UUCP (Dave Brower) (09/26/85)
> On a Dec-20, you have a huge number of strange instructions, including : ... > skipn : skip never > jumpn : jump never I always assumed these instructions 'existed' out of dedication to orthogonality in the instruction set. The DEC 10/20 seemed to have about a bizzilion instructions that boiled down to NOP. The advantage was that it was easy to learn the mnemonics, since they were all constructed in a regular fashion. It was also very easy to create and examine object code: all the instructions are the same size, and the scheme for modifying operand types is also very regular. Stanford had an ungodly quick one-pass assembler called FAIL that worked because it always knew how big an instruction was (one 36 bit word), and because it had the linker try to resolve all of the forward references. -- {amdahl|dual|sun|zehntel}\ |"If his brains ran down, how could {ucbvax|decvax}!mtxinu---->!rtech!daveb |he talk?" ihnp4!{phoenix|amdahl}___/ |"Happens to people all the time...."
weltyrp@rpics.UUCP (Richard Welty) (10/03/85)
> > On a Dec-20, you have a huge number of strange instructions, including : > ... > > skipn : skip never > > jumpn : jump never > > I always assumed these instructions 'existed' out of dedication to > orthogonality in the instruction set. The DEC 10/20 seemed to have > about a bizzilion instructions that boiled down to NOP. The advantage > was that it was easy to learn the mnemonics, since they were all > constructed in a regular fashion. It was also very easy to create and > examine object code: all the instructions are the same size, and the > scheme for modifying operand types is also very regular. Stanford had One more reason why they existed: When the PDP-6 was developed in the early sixties, DEC was a small company trying to compete in a big world. Allowing the massive number of nops was a way to keep the hardware small and simple, and thus fast and cheap -- it is harder not to have such instructions. -- Rich Welty (I am both a part-time grad student at RPI and a full-time employee of a local CAE firm, and opinions expressed herein have nothing to do with anything at all) CSNet: weltyrp@rpi ArpaNet: weltyrp.rpi@csnet-relay UUCP: seismo!rpics!weltyrp