bartonr@psu-cs.UUCP (Robert Barton) (03/02/89)
I have a variable, called code, representing a word of machine code which consists of one or more bit fields of various sizes. Since I will be doing a number of bit manipulation operations on this variable it has been declared with type BITSET. However for testing purposes it will be useful to assign code various values within a given range using a loop. Now the problem: using the statement INC(CARDINAL(code), 1); the compiler gives an error message of "variable expected". Does this sound like a compiler bug or an error on my part? The references I have read indicate that INC should take any ordinal type, including CARDINAL. BITSET and CARDINAL are both 16 bits in this implementation. Using code := BITSET(CARDINAL(code) + 1); is acceptable to the compiler, so I can work around it, but I'm just wondering if anyone else has come across this.
ags@s.cc.purdue.edu (Dave Seaman) (03/03/89)
In article <1712@psu-cs.UUCP> bartonr@psu-cs.UUCP (Robert Barton) writes: >Now the problem: using the statement > > INC(CARDINAL(code), 1); > >the compiler gives an error message of "variable expected". Correct. The first argument to INC must be a variable. The first argument that you specified is CARDINAL(code) which is not a variable. It's an expression. You may want to declare code as a variant record so that you can access it as any data type you want. Alternatively, you could use code := BITSET(CARDINAL(code)+1) to do what you want. -- Dave Seaman ags@j.cc.purdue.edu
aubrey@val.UUCP (Aubrey McIntosh) (03/04/89)
In article <1712@psu-cs.UUCP> bartonr@psu-cs.UUCP (Robert Barton) writes: >Now the problem: using the statement > > INC(CARDINAL(code), 1); > >the compiler gives an error message of "variable expected". The compilers I have used call CARDINAL() a function; they then get difficult about not allowing assignments to function values. I spent a long time chasing this one down. A similar one that bits me is: VAR v1 : recPtr; ... recPtr( cardinalvariable ) ^ := expression I still don't know why I can't dereference a pointer function type, but it seems to be forbidden. -- -------------------------------------------------------------- a Modula-2 house... 1-(512)-346-5781 (v) Austin, TX 78759 ...!cs.utexas.edu!oakhill!val!aubrey
bnilsson@watdragon.waterloo.edu (Bengt J Nilsson) (03/04/89)
In article <1712@psu-cs.UUCP> bartonr@psu-cs.UUCP (Robert Barton) writes: > > I have a variable, called code, representing a word of machine code >which consists of one or more bit fields of various sizes. Since I will >be doing a number of bit manipulation operations on this variable it has >been declared with type BITSET. However for testing purposes it will be >useful to assign code various values within a given range using a loop. >Now the problem: using the statement > > INC(CARDINAL(code), 1); > >the compiler gives an error message of "variable expected". Does this >sound like a compiler bug or an error on my part? The references I have >read indicate that INC should take any ordinal type, including CARDINAL. >BITSET and CARDINAL are both 16 bits in this implementation. Using > > code := BITSET(CARDINAL(code) + 1); > >is acceptable to the compiler, so I can work around it, but I'm just >wondering if anyone else has come across this. I'm afraid it's an error on your part. The error message is absolutely correct, it expects a variable, not an expression. You see, INC requires a named variable to work on, and the CARDINAL operation copies the value of its parameter and gives it (the copied value) the new type. So the equivalent (correct) to your code would be. x := CARDINAL( code ); INC( x, 1 ); code := BITSET( x ); But apparently you shorted it down a bit. Hope this explains it. ---Bengt bnilsson@watdragon.waterloo.edu on visit from Lund University, Sweden bengt@dna.lu.se
joel@WSL.DEC.COM (03/04/89)
INC(CARDINAL(code), 1); is not accepted by most Modula-2 compilers, because ``CARDINAL(code)'' is an expression (an r-value, for those conversant with C's description) rather than a variable (an l-value). INC effectively takes a VAR parameter, so insists upon having a variable. I don't consider the cast to really be an expression. I see it as a type conversion which is more properly seen as a viewpoint change rather than a computation. I therefore consider this a silly restriction, and done something about it in the Modula-2 compiler I maintain. But it certainly isn't standard. Joel McCormack
dwight@sugar.hackercorp.com (Dwight Everhart) (03/05/89)
In article <291@val.UUCP>, aubrey@val.UUCP (Aubrey McIntosh) writes: > The compilers I have used call CARDINAL() a function; they then get difficult > about not allowing assignments to function values. I spent a long time chasing > this one down. > > A similar one that bits me is: > VAR v1 : recPtr; > ... > recPtr( cardinalvariable ) ^ := expression > I still don't know why I can't dereference a pointer function type, but it > seems to be forbidden. These are the two aspects of M2 that annoy me the most, even though I love the language in general. -- Dwight Everhart | "Time is an illusion. dwight@sugar.uu.net | Lunchtime doubly so." {uunet,texbell}!sugar!dwight | -- Ford Prefect
R_Tim_Coslet@cup.portal.com (03/05/89)
In Article: <291@val.UUCP> aubrey@val.UUCP (Aubrey McIntosh) Writes: > recPtr( cardinalvariable ) ^ := expression >I still don't know why I can't dereference a pointer function type, but it >seems to be forbidden. This is forbidden, because "pointers" and "cardinals" may not be the same size and the "pointers" may not "have the same structure" as "cardinals" do. For example many 8086 implementations of pointers use a 32 bit number: the upper 16 bits contain the "segment" and the lower 16 bits contain the "address" in that "segment". The 8086 uses this to generate a 20 bit address. Pointer: ssssaaaa ssss0 aaaa ----- xxxxx = Physical memory address "casting" a cardinal to a pointer on this machine would produce garbage. A better way to do it is to implement a "machine-specific" variant record definition (with no tag variable). Then if you need to generate a "custom" pointer you assign to the fields under one name and use them under the other... trick.addr := {machine specific value(s)...} trick.val^ := expression R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
bartonr@psu-cs.UUCP (Robert Barton) (03/07/89)
Many thanks to all who responded via net or mail to my question about
INC(CARDINAL(variableDeclaredAsBitset));
generating a "variable expected" error. I suspected I was doing something
wrong, but I couldn't figure out what from the references I had at hand.
The explanation concerning l-values versus r-values makes sense. A couple
people also provided the "virtual declaration" of INC() as a compiler sees
it. It would be nice to have a list of these for the various standard
procedures if anyone could point me to one. Thanks again for all the help
and suggestions.alan@pdn.nm.paradyne.com (Alan Lovejoy) (03/08/89)
In article <8903032139.AA00466@gilroy.pa.dec.com> Modula2 List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: > >INC(CARDINAL(code), 1); > >is not accepted by most Modula-2 compilers, because ``CARDINAL(code)'' is an >expression (an r-value, for those conversant with C's description) rather than >a variable (an l-value). INC effectively takes a VAR parameter, so insists >upon having a variable. > >I don't consider the cast to really be an expression. I see it as a type >conversion which is more properly seen as a viewpoint change rather than a >computation. I therefore consider this a silly restriction, and done >something about it in the Modula-2 compiler I maintain. But it certainly >isn't standard. > > Joel McCormack *Syntactically*, "CARDINAL(BITSET{2,5})" is an expression. The only way to differentiate between this and any other expression is by means of the semantics. If the parser permits expressions everywhere that "idents" and/or "qualidents" are allowed, then it must rely on the semantic analyzer to distinguish between legal and illegal expression usage. But Wirth published a grammar for Modula-2 that explicitly outlawed the usage of what are syntactically expressions in cases like the one above. So any compiler that relaxes this restriction is not standard. The fact that the resulting language may be an improvement over the one defined by Wirth has not been enough to motivate most compiler writers, whose work so far is largely a labor of love. The international standardization effort is the last great hope for addressing this issue. From what I have heard, I wouldn't expect any changes that would allow "INC(CARDINAL(x), 1)" anytime soon, unfortunately. If you want to complain about the shortcomings of M2, start with the fact that modules are not classes, and don't forget to mention the lack of an inheritance mechanism and parametric types/modules. -- Alan Lovejoy; alan@pdn; 813-530-2211; ATT-Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for ATT-Paradyne. They do not speak for me. ___________ This Month's Slogan: Reach out and BUY someone (tm). ___________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
joel@WSL.DEC.COM (03/13/89)
Like I said, treating casts as something different from functions, even though they look the same, isn't standard. But one can very easily argue that the reason it wasn't included in Modula-2 was the small implementation hassles. Changing the grammar is trivial enough, and you would have ended up not having stupid discussions on the net when someone tries do something reasonable. Module variables and inheritance is another story. Yes, I'd like a real nice object-oriented and strongly-typed language. But that won't come from making trivial changes to Modula-2. Joel McCormack