jnp@daimi.UUCP (J|rgen N|rgaard) (11/14/86)
Small bug in MacMETH 2.0 Toolbox interface:
Menumanager: GetIconItem
the result parameter is a "VAR IconItem:Byte", due to modulas
way of handling BYTEs this is wrong. Pascal and modula use
exactly the opposite BYTEs of a WORD when accessing just one
BYTE.
One solution could be: (in interface module of course)
VAR dirty : RECORD
b1,b2:BYTE
END;
..........
GetIconItem(parameter1,parameter2, dirty.b1);
assign dirty.b2 to the return parameter.
If there is any interest I'll post a translation of a TML-pascal
example of a menudefinition-procedure, entirely written in MODULA-2.
It is the "trivial" case: the standard menu definition redefined.
But then in can be extended to interesting cases like Macdraws
"Pattern"-menu.
This bug is likely to occur everywhere BYTEs are used as parameters.
Not checked out.
(Mail me if you see this C. Pfister; implememtor of the toolbox-interface).bobc@tikal.UUCP (Bob Campbell) (11/18/86)
In article <446@daimi.UUCP> jnp@daimi.UUCP (J|rgen N|rgaard) writes: >Small bug in MacMETH 2.0 Toolbox interface: >the result parameter is a "VAR IconItem:Byte", due to modulas >way of handling BYTEs this is wrong. Pascal and modula use >exactly the opposite BYTEs of a WORD when accessing just one >BYTE. .... >One solution could be: (in interface module of course) > VAR dirty : RECORD > b1,b2:BYTE > END; >.......... > GetIconItem(parameter1,parameter2, dirty.b1); PROCEDURE GetItemIcon(theMenu:MenuHandle;item:INTEGER;VAR icon:CHAR); Either the definition is wrong (and I believe that it is correct as per Inside Mac but I have not checked), or there are serious problems. Neither the Mac nor MacMETH should assume that when a BYTE size variable is passed that the address of the real byte is the address passed + 1, this just does not make since to me. I do know that value parameters are passed differently as MacMETH uses MOVE.B xxx,-(A7) and the normal Mac routines used MOVE.W xxx,-(A7). The MacMETH code is something like follows: PROCEDURE Example(VAR b:BYTE); BEGIN b := 0C; END Example; VAR x:BYTE; BEGIN Example(x); END ... example LINK A6,#0 MOVE.B #0,8(A6) UNLK A6 MOVEA.L (A7)+,A3 ; I believe that it uses A3 most of the time LEA 4(A7),A7 ; Pop Parameter JMP (A3) ; Return PEA x,-(A7) BSR Example OR for a trap routine PROCEDURE Examp(VAR b:BYTE); CODE 0A9FFH; VAR x:BYTE; BEGIN Examp(x); END ... PEA x,-(A7) DC.W A9FF At this point you have passed the address of the exact byte that you want it to work with. If it messes with something else then there are big problems, I don't beleive that either MacMETH or the MacIntosh ROMs would do this (unless there is a bug). I would like to here what the final resolution of this problem is, (and may do some experments at home to find out). Bob Campbell Teltone Corporation 18520 - 66th AVE NE P.O. Box 657 Seattle, WA 98155 Kirkland, WA 98033 {amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc
bobc@tikal.UUCP (Bob Campbell) (11/19/86)
In article <446@daimi.UUCP> jnp@daimi.UUCP (J|rgen N|rgaard) writes: >Small bug in MacMETH 2.0 Toolbox interface: >the result parameter is a "VAR IconItem:Byte", due to modulas >way of handling BYTEs this is wrong. Pascal and modula use >exactly the opposite BYTEs of a WORD when accessing just one >BYTE. .... >One solution could be: (in interface module of course) > VAR dirty : RECORD > b1,b2:BYTE > END; >.......... > GetIconItem(parameter1,parameter2, dirty.b1); PROCEDURE GetItemIcon(theMenu:MenuHandle;item:INTEGER;VAR icon:CHAR); Either the definition is wrong (and I believe that it is correct as per Inside Mac but I have not checked), or there are serious problems. Neither the Mac nor MacMETH should assume that when a BYTE size variable is passed that the address of the real byte is the address passed + 1, this just does not make since to me. I do know that value parameters are passed differently as MacMETH uses MOVE.B xxx,-(A7) and the normal Mac routines used MOVE.W xxx,-(A7). The MacMETH code is something like follows: PROCEDURE Example(VAR b:BYTE); BEGIN b := 0C; END Example; VAR x:BYTE; BEGIN Example(x); END ... example LINK A6,#0 ; Link A6 MOVEA.L 8(A6),A3 ; Get the address of b MOVE.B #0,(A3) ; Store 0 into b UNLK A6 ; Unlink MOVEA.L (A7)+,A3 ; I believe that it uses A3 most of the time LEA 4(A7),A7 ; Pop Parameter JMP (A3) ; Return PEA x,-(A7) ; Push Address of x BSR Example ; Call Example OR for a trap routine PROCEDURE Examp(VAR b:BYTE); CODE 0A9FFH; VAR x:BYTE; BEGIN Examp(x); END ... PEA x,-(A7) DC.W A9FF At this point you have passed the address of the exact byte that you want it to work with. If it messes with something else then there are big problems, I don't beleive that either MacMETH or the MacIntosh ROMs would do this (unless there is a bug). I would like to here what the final resolution of this problem is, (and may do some experments at home to find out). Bob Campbell Teltone Corporation 18520 - 66th AVE NE P.O. Box 657 Seattle, WA 98155 Kirkland, WA 98033 {amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc
joel@gould9.UUCP (Joel West) (11/23/86)
It is safe to assume that if one generates straightforward 68000
code to pass the address of a byte, that the byte will be represented
as the upper half of a 16-bit word. This is well documented, on
IM Vol I, page 93.
This is not a problem for a Pascal CHAR, since they are stored as
16-bit INTEGER, except in PACKED array or record.
Anyone who's read the assembly language chapter should be able
to get this right....
--
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPA