CompuServe Thread

#27593From: Mike BerroJul 23, 1986 8:12 PM

btst checks all 32 bits if you are testing a data register, 8 bits if testing a memory location. I solved my problem, see msg reply to #27583. Thanx!

#27593From: Mike BerroJul 23, 1986 8:12 PM

btst checks all 32 bits if you are testing a data register, 8 bits if testing a memory location. I solved my problem, see msg reply to #27583. Thanx!

#27686From: GARY SARFFJul 24, 1986 3:42 AM

Scott, what is this about btst only testing bits mod 8? Is that from Lattice C or what? When I was doing Icon there were many references as you probably saw to things like D_VAR and such (Masks for different descriptor types) and one was for example 0x40000000 and it was supposed to be ANDed with a value. It compiles to a btst #$1E,<something> on the wicat but lattice would insist on compiling it as btst 6,<something> Actually testing the wrong bit!! Is that what you mean? That was driving me insane. Had to go through all kinds of gyrations to get lattice to produce the proper code. Does Aztec do this too? If so, watch out when you get 6.0 to work on.

#27805From: Scott BallantyneJul 25, 1986 2:22 AM

Blech! Well, it BTST only tests the lowest 7 bits in a memory location – but it works ok, apparently, on data registers. This was news to me. (But good news.) So if you btst #9,memory you are testing bit 1, but btst #9,<dn> works ok. Lattice…. Manx does ok as far as this stuff goes. Did you get my letter?? Send me mail, so I know what to send you! sdb

#28053From: GARY SARFFJul 27, 1986 10:48 AM

Why was testing only the low 7 bits good news to you? I would think it was bad news. Excuse my ignorance but are you saying that this btst thing is with the 68000 itself, amiga or lattice C? I've used the symbolic debugger on the wicat and put $80000000 in a memory location and done a btst $1f,loc and gotten indication that the 31'st bit was set, so what gives? But I do know that lattice would compile something like x & 0x80000000 as a btst 7,x which is testing the wrong bit for sure. It would be better if lattice would just do an AND if they are going to generate improper code this way. Oh, I realized I forgot to answer you question about the binary files on the Gnu Emacs tape. As far as I know they are unix core images for the "compiled" lisp routines in gnu emacs and you can safely ignore them, since you can read in the text for the lisp routines to emacs and compile them whenever you want. Bye

#28125From: Scott BallantyneJul 27, 1986 11:05 PM

I meant that btst working properly on a data register was good news. I thought it always just tested 8 bits… All I know is what I read – I haven't (obviously) tried it out – the 68000 book(s ??) say that the btst instruction only works on the low 8 bits. Somebody else here said that is only true if you do it on a memory location – it works ok in a register. No you say it works ok, no matter what. I am just cornfused…. Maybe Motorola made a new chip rev, and didn't tell anybody this had been changed? (Ah – just realized, the 68000 book I read that said this was by the same guy that wrote AmigaDOG. Draw your own conclusions.) sdb

#28142From: Larry Phillips/ICUGJul 28, 1986 12:27 AM

According to Motorola's Programer's Reference Manual (1984) "… if a data register is the destination, then the bit number is modulo 32, allowing bit manipulation on all bits in a register. If a memory location is the destination, a byte is read from that location,and the bit operation performed using the bit number modulo 8 with zero referring to the least-significant bit."

#28142From: Larry Phillips/ICUGJul 28, 1986 12:27 AM

According to Motorola's Programer's Reference Manual (1984) "… if a data register is the destination, then the bit number is modulo 32, allowing bit manipulation on all bits in a register. If a memory location is the destination, a byte is read from that location,and the bit operation performed using the bit number modulo 8 with zero referring to the least-significant bit."

#28169From: Don Curtis/SYSOPJul 28, 1986 1:56 AM

Both of my Motorola books (68000 and 68020 manuals from Motorola) agree with your information. 32 bit test is only available in a register. A test done in memory is 8 bit only.

#28169From: Don Curtis/SYSOPJul 28, 1986 1:56 AM

Both of my Motorola books (68000 and 68020 manuals from Motorola) agree with your information. 32 bit test is only available in a register. A test done in memory is 8 bit only.

#28190From: GARY SARFFJul 28, 1986 10:59 AM

I guess you are right, I'm mistaken about btst. I've compiled Icon 6.0 and am working on getting it running now. Our C compiler compiles something like x & D_VAR (which you see a lot in Icon, testing for a variable descriptor ) as move.l _x,d0 btst $1f,d0 bne <somewhere> where D_VAR is #define'd as 0x80000000 Now lattice will do a btst 7. I have tried everything I can think of to get it to generate code that will test the 31'st bit. I've used variables instead of the constant, I can't figure this out. Somebody should tell lattice anyway, if they can't do it right, they could at least have the compiler do something like loading x into a reg and ANDing it with 0x80000000. This makes me very mad, since as you know well, there are descriptors all over the place in Icon made up by anding and oring constants together declared in the header files. Like the Procedure descriptor which is supposed to be 0x80000000 | 0x10000000 | 0x00000006 which should be 0x90000006. If all that above was #define'd as some symbol, say D_PROC and I do an mainp=D_PROC I would expect mainp to be assigned 0x90000006 and on the wicat it is. On lattice on amiga it gets some gibberish like 0x00000406 or some such junk. I mean come on! How does manx do with that stuff in version 5.9 did you ever check the code to make sure those masks were being generated properly?

#28255From: Don Curtis/SYSOPJul 29, 1986 12:35 AM

A quick look in my Motorola book shows that to test the 31st bit of a data register (D0), the proper syntax is: btst #$1f,D0 Your example showed, btst $1f,D0

#28279From: GARY SARFFJul 29, 1986 10:11 AM

It depends on the assembler syntax I suppose. The motorola mnemonics which our wicat uses and amiga, does indeed use btst #$1f,d0, but then again some other systems like the SUN use btst 0x1f,d0 like C and stuff like movl a6@(8),d0 where Motorola would use move.l 8(a6),d0. I'm used to the SUN mnemonics my self, but we've gotten a new assembler at work that now uses the Motorola ones and I'm having to relearn.

#28279From: GARY SARFFJul 29, 1986 10:11 AM

It depends on the assembler syntax I suppose. The motorola mnemonics which our wicat uses and amiga, does indeed use btst #$1f,d0, but then again some other systems like the SUN use btst 0x1f,d0 like C and stuff like movl a6@(8),d0 where Motorola would use move.l 8(a6),d0. I'm used to the SUN mnemonics my self, but we've gotten a new assembler at work that now uses the Motorola ones and I'm having to relearn.

#28255From: Don Curtis/SYSOPJul 29, 1986 12:35 AM

A quick look in my Motorola book shows that to test the 31st bit of a data register (D0), the proper syntax is: btst #$1f,D0 Your example showed, btst $1f,D0

#28276From: Scott BallantyneJul 29, 1986 2:56 AM

I remember you warned me about this – I did check on it. Manx invariably uses and: and.l #$80000000,d3 beq <somewhere> The irritating think about manx is that if you do a #define D_PROC 0x80000000 | 0x10000000 | 0x00000006 then you get code like this: and.l #$80000000,d3 or.l #$10000006,d3 tst.l d3 <branch somewhere> Which is not exactly efficient. You have to #define D_PROC 0x90000006 to get and.l #$90000006,d3 <branch> which is better. Might seem a small point, but I don't understand why their code generator works this way – especially since such tests are pretty frequent… not just in Icon.

#28280From: GARY SARFFJul 29, 1986 10:18 AM

Thanks. I will get busy when I get it. I'm sorry about the tape I sent being so hard to use. Would some other format have been better? I remember you saying something one time about it being 80 byte fixed records or something? I could make a new one for you and try again. We've got lots of 9track tapes here. We get software and OS updates on them and after they are loaded on the hard disk I don't need the tapes anymore, I've got about 3 racks of them now. As for Manx, apparently they aren't doing any folding when they compile the code. Folding lets the compiler compute expressions whose values are either constants or variables whose values can be determined at compile time so that the expression isn't evaluated at run time. That is suprising since Manx is supposed to be so good. Apparently Lattice IS attempting to do folding, if only they would get the correct answer when they do it!

#28349From: Scott BallantyneJul 30, 1986 6:00 AM

Yes – I was surprised at the manx code as well. In general, it appears that lattice does better at this sort of optimization, as well as handling temporary values, stuff like that. Supposedly – the new update is supposed to improve a lot of this sort of stuff, as well as allow the use of A6 as the stack frame pointer. (I got on my knees and pleaded for that one, but now maybe we don't need it? Oh well…) Well, I finally did manage to get the whole tape over to a format the CV system can cope with. I think any tape format would have been difficult. CV even uses it's own version of ASCII, which was also a bit of a pain. But it's done. Now, I still need that magic formula to get it on the Amiga. (Wouldn't mind it on a CV – but guess what, no C compiler. Argh!) So save your tapes – there's nothing you can do that would make it easier – CV has taken care of that. Got Icon up on the Wicat yet? sdb

#28409From: Charlie HeathJul 31, 1986 12:09 AM

Actually the code was produced that way cause of a lack of parenthesis.

#28409From: Charlie HeathJul 31, 1986 12:09 AM

Actually the code was produced that way cause of a lack of parenthesis.

#28349From: Scott BallantyneJul 30, 1986 6:00 AM

Yes – I was surprised at the manx code as well. In general, it appears that lattice does better at this sort of optimization, as well as handling temporary values, stuff like that. Supposedly – the new update is supposed to improve a lot of this sort of stuff, as well as allow the use of A6 as the stack frame pointer. (I got on my knees and pleaded for that one, but now maybe we don't need it? Oh well…) Well, I finally did manage to get the whole tape over to a format the CV system can cope with. I think any tape format would have been difficult. CV even uses it's own version of ASCII, which was also a bit of a pain. But it's done. Now, I still need that magic formula to get it on the Amiga. (Wouldn't mind it on a CV – but guess what, no C compiler. Argh!) So save your tapes – there's nothing you can do that would make it easier – CV has taken care of that. Got Icon up on the Wicat yet? sdb

#28280From: GARY SARFFJul 29, 1986 10:18 AM

Thanks. I will get busy when I get it. I'm sorry about the tape I sent being so hard to use. Would some other format have been better? I remember you saying something one time about it being 80 byte fixed records or something? I could make a new one for you and try again. We've got lots of 9track tapes here. We get software and OS updates on them and after they are loaded on the hard disk I don't need the tapes anymore, I've got about 3 racks of them now. As for Manx, apparently they aren't doing any folding when they compile the code. Folding lets the compiler compute expressions whose values are either constants or variables whose values can be determined at compile time so that the expression isn't evaluated at run time. That is suprising since Manx is supposed to be so good. Apparently Lattice IS attempting to do folding, if only they would get the correct answer when they do it!

#28508From: wayne hamiltonAug 1, 1986 1:29 AM

manx is doing it right. suppose you had said: #define pi 3.0+.14 followed by: area = (r*r)*pi; would you expect the "right" answer? what you'd get is: area = (r*r)*3.0+.14; evaluated as: area = ((r*r)*3.0)+.14; the same thing is happening with boolean instead of arithmetic operators. put parens in your #define and you get what you really(?) wanted. it even "folds" constants.

#28745From: John FoustAug 3, 1986 2:24 PM

Operator precedence strikes again. I always get & and | mixed up, in terms of precedence. Gary Sarff, then how did this fragment of Icon code ever work in the first place? Harbison & Steel, pg. 141, says bitwise & is left associative, level 8 in precedence; bitwise | is 6L. Exclusive OR sits in-between, at level 7L. I think this discussion is interesting in its own right, it's not a complaint about Manx, of course. I'm interested in compiler theory. I've been visiting Ed Ream again, the guy who's writing the PL/68K dial-a-brew assembler/C compiler. It's compiling itself already! He's doing it under CP/M 68K, so maybe it will be easier to port to the Atari ST than the Amiga… :=)

#28745From: John FoustAug 3, 1986 2:24 PM

Operator precedence strikes again. I always get & and | mixed up, in terms of precedence. Gary Sarff, then how did this fragment of Icon code ever work in the first place? Harbison & Steel, pg. 141, says bitwise & is left associative, level 8 in precedence; bitwise | is 6L. Exclusive OR sits in-between, at level 7L. I think this discussion is interesting in its own right, it's not a complaint about Manx, of course. I'm interested in compiler theory. I've been visiting Ed Ream again, the guy who's writing the PL/68K dial-a-brew assembler/C compiler. It's compiling itself already! He's doing it under CP/M 68K, so maybe it will be easier to port to the Atari ST than the Amiga… :=)

#28508From: wayne hamiltonAug 1, 1986 1:29 AM

manx is doing it right. suppose you had said: #define pi 3.0+.14 followed by: area = (r*r)*pi; would you expect the "right" answer? what you'd get is: area = (r*r)*3.0+.14; evaluated as: area = ((r*r)*3.0)+.14; the same thing is happening with boolean instead of arithmetic operators. put parens in your #define and you get what you really(?) wanted. it even "folds" constants.

#28276From: Scott BallantyneJul 29, 1986 2:56 AM

I remember you warned me about this – I did check on it. Manx invariably uses and: and.l #$80000000,d3 beq <somewhere> The irritating think about manx is that if you do a #define D_PROC 0x80000000 | 0x10000000 | 0x00000006 then you get code like this: and.l #$80000000,d3 or.l #$10000006,d3 tst.l d3 <branch somewhere> Which is not exactly efficient. You have to #define D_PROC 0x90000006 to get and.l #$90000006,d3 <branch> which is better. Might seem a small point, but I don't understand why their code generator works this way – especially since such tests are pretty frequent… not just in Icon.

#28190From: GARY SARFFJul 28, 1986 10:59 AM

I guess you are right, I'm mistaken about btst. I've compiled Icon 6.0 and am working on getting it running now. Our C compiler compiles something like x & D_VAR (which you see a lot in Icon, testing for a variable descriptor ) as move.l _x,d0 btst $1f,d0 bne <somewhere> where D_VAR is #define'd as 0x80000000 Now lattice will do a btst 7. I have tried everything I can think of to get it to generate code that will test the 31'st bit. I've used variables instead of the constant, I can't figure this out. Somebody should tell lattice anyway, if they can't do it right, they could at least have the compiler do something like loading x into a reg and ANDing it with 0x80000000. This makes me very mad, since as you know well, there are descriptors all over the place in Icon made up by anding and oring constants together declared in the header files. Like the Procedure descriptor which is supposed to be 0x80000000 | 0x10000000 | 0x00000006 which should be 0x90000006. If all that above was #define'd as some symbol, say D_PROC and I do an mainp=D_PROC I would expect mainp to be assigned 0x90000006 and on the wicat it is. On lattice on amiga it gets some gibberish like 0x00000406 or some such junk. I mean come on! How does manx do with that stuff in version 5.9 did you ever check the code to make sure those masks were being generated properly?

#28125From: Scott BallantyneJul 27, 1986 11:05 PM

I meant that btst working properly on a data register was good news. I thought it always just tested 8 bits… All I know is what I read – I haven't (obviously) tried it out – the 68000 book(s ??) say that the btst instruction only works on the low 8 bits. Somebody else here said that is only true if you do it on a memory location – it works ok in a register. No you say it works ok, no matter what. I am just cornfused…. Maybe Motorola made a new chip rev, and didn't tell anybody this had been changed? (Ah – just realized, the 68000 book I read that said this was by the same guy that wrote AmigaDOG. Draw your own conclusions.) sdb

#28214From: Charlie HeathJul 28, 1986 8:49 PM

The btst "bug" is a 68000 limitation – it only has a byte addressing mode for memory references. If testing against any specific bit, a compiler can figure out which of two bytes in a word or which of 4 bytes in a long should be tested and generate the appropriate byte ref.

#28214From: Charlie HeathJul 28, 1986 8:49 PM

The btst "bug" is a 68000 limitation – it only has a byte addressing mode for memory references. If testing against any specific bit, a compiler can figure out which of two bytes in a word or which of 4 bytes in a long should be tested and generate the appropriate byte ref.

#28320From: wayne hamiltonJul 29, 1986 11:44 PM

The high-order byte, the one containing the 1-bit in a longword $800000, is at the low address, so "btst #31.,loc" would work as well as "btst #7,loc"; 31 mod 8 is 7. try testing a low-order bit (say, "loc&0x4"), in a longword and see if the compiler is smart enough to generate a "btst #2,loc+3". while i'm on the subject, the original questioner (dan lovy?) posted a code fragment showing his switch from cmp's to btst's; he wondered why his braches were taken in a strange way. did anyone mention to him that the sense of the branches change between "cmp" and "btst"? tst is a compare-against-zero, so where you'd "beq" after a "cmp", you "bne" after a "btst". wayne ps: add a couple more 0's to that $800… above.

#28320From: wayne hamiltonJul 29, 1986 11:44 PM

The high-order byte, the one containing the 1-bit in a longword $800000, is at the low address, so "btst #31.,loc" would work as well as "btst #7,loc"; 31 mod 8 is 7. try testing a low-order bit (say, "loc&0x4"), in a longword and see if the compiler is smart enough to generate a "btst #2,loc+3". while i'm on the subject, the original questioner (dan lovy?) posted a code fragment showing his switch from cmp's to btst's; he wondered why his braches were taken in a strange way. did anyone mention to him that the sense of the branches change between "cmp" and "btst"? tst is a compare-against-zero, so where you'd "beq" after a "cmp", you "bne" after a "btst". wayne ps: add a couple more 0's to that $800… above.

#28053From: GARY SARFFJul 27, 1986 10:48 AM

Why was testing only the low 7 bits good news to you? I would think it was bad news. Excuse my ignorance but are you saying that this btst thing is with the 68000 itself, amiga or lattice C? I've used the symbolic debugger on the wicat and put $80000000 in a memory location and done a btst $1f,loc and gotten indication that the 31'st bit was set, so what gives? But I do know that lattice would compile something like x & 0x80000000 as a btst 7,x which is testing the wrong bit for sure. It would be better if lattice would just do an AND if they are going to generate improper code this way. Oh, I realized I forgot to answer you question about the binary files on the Gnu Emacs tape. As far as I know they are unix core images for the "compiled" lisp routines in gnu emacs and you can safely ignore them, since you can read in the text for the lisp routines to emacs and compile them whenever you want. Bye

#27805From: Scott BallantyneJul 25, 1986 2:22 AM

Blech! Well, it BTST only tests the lowest 7 bits in a memory location – but it works ok, apparently, on data registers. This was news to me. (But good news.) So if you btst #9,memory you are testing bit 1, but btst #9,<dn> works ok. Lattice…. Manx does ok as far as this stuff goes. Did you get my letter?? Send me mail, so I know what to send you! sdb

#27686From: GARY SARFFJul 24, 1986 3:42 AM

Scott, what is this about btst only testing bits mod 8? Is that from Lattice C or what? When I was doing Icon there were many references as you probably saw to things like D_VAR and such (Masks for different descriptor types) and one was for example 0x40000000 and it was supposed to be ANDed with a value. It compiles to a btst #$1E,<something> on the wicat but lattice would insist on compiling it as btst 6,<something> Actually testing the wrong bit!! Is that what you mean? That was driving me insane. Had to go through all kinds of gyrations to get lattice to produce the proper code. Does Aztec do this too? If so, watch out when you get 6.0 to work on.

#27749From: Charlie HeathJul 24, 1986 9:53 PM

You can btst more on a register – but not on a memory reference. Also and even narstier, on a memory reference it gets the high byte of a word reference. Argh.

#27806From: Scott BallantyneJul 25, 1986 2:23 AM

Charming. Do you know if this is fixed on the 68020, perchance?

#27806From: Scott BallantyneJul 25, 1986 2:23 AM

Charming. Do you know if this is fixed on the 68020, perchance?

#27749From: Charlie HeathJul 24, 1986 9:53 PM

You can btst more on a register – but not on a memory reference. Also and even narstier, on a memory reference it gets the high byte of a word reference. Argh.

#IDCMP