long and integer
BlitzMax Forums/BlitzMax Programming/long and integer
| ||
| I have a problem. I suspect it is a bug. it arouse from the need to find out if a long was also a negative. this is the test: SuperStrict Local a:Int = $7fffffff '32 bit Local b:Long = $7fffffff7fffffff '64 bit. Print a Print b Print Hex(a) Print Hex(b) Print (long(a)<b) ' this should print 1 but does not. why is the long variable truncated into an integer? ****************sorrry about the edits I had to make it more clear ************ |
| ||
| Well I'm not sure - but this looks OK to me. a and b are both -1, since they are both settings all their bits to 1, which under the two's complement system is -1 The Hex() function takes an integer as an argument, so b is converted to an integer as it goes in. a > b is comparing apples with oranges unless they are converted to the same type at some stage. So you would expect the compiler to force b to an integer on the test. As things stand you really are asking if -1 > -1 anyway? But then again, I could be wrong by a country mile... |
| ||
| sorry, wrong code. try it now. a > b is comparing apples with oranges unless they are converted to the same type at some stage to answer that, it should all be converted to long according to the documentation. but I did an edit for that yust to show you. |
| ||
SuperStrict Local a:Int = $7fffffff '32 bit Local b:Long = $7fffffffffffffff:Long '64 bit. Print a Print b Print Hex(a) Print Hex(b) Print (a<b) ' this should print 1 but does not. Fixed. You forgot to specify that the number was a Long. By default, numbers you specify are either integers or doubles (or floats, I can't remember what the rule is regarding floating point numbers). |
| ||
| Ha ha - your code switch sure baffled me. I posted and went "hang on"... I'm sure those numbers were different before! Well it looks to me that it is converting b to integers at each level. To do so, it is just taking the leftmost bits. If you change a to: $7effffff you'll see what I mean. Whether this is the documented/intended behaviour I don't know - but it seems reasonable enough to me. I suppose the Print should ideally get it right though... |
| ||
| Or maybe I should just keep my mouth shut :-) Thanks for clearing that up Noel! |
| ||
| Nilium, thanks! flashback... Went down that road by myself before. can't believe I forgot. :) |
| ||
| Am I alone in thinking that it's a bit weird to have to tell the compiler twice you want a long? |
| ||
| I do too but I think it makes compiling faster while it don't have to figure out what you want sence it compiles from right to left. Don't quote me. I think I read that somewhere in the forums before. |
| ||
| Am I alone in thinking that it's a bit weird to have to tell the compiler twice you want a long? I think this is mostly down to the most common number being an integer (and within the range of an integer), so it's probably faster in the long run; I don't know that that is the case though. The compiler might be able to be tweaked to recognize the context the number is in, but I'm not familiar with writing compilers and I won't try to claim that it's a good design decision, much less that it's easy to do. |
| ||
| I believe that the new processors work with 64 bit registers but sence I have not looked at assembly language sence the 80586 processors I don't know anymore. if the language would take full advantage of that I would say that the 64 bit long would be fastest if the language would take advantage of that but that is just my opinion (full of ignorance now :)). I guess backward compatability would make not so. |
| ||
| Integers are by far the fastest. Even bytes are not usually faster despite being 1/4 the amount of memory access. I tested speeds of all types and Integer is fastest, and actually Longs are quite slow. I don't know if they would be any faster on a 64-bit system. |
| ||
| integers are placed in 32 bit registers as set by most computers except if it were to take advantage of the 64 bit registers if any. yes, I have read that the 64 bit architecture was not as fast as spected and that in "some" instances 32 bit is even faster but as I said, I am not up to date. So let me stop now. Don't hurt me please! :) |
| ||
| in assembly adding ebx(32 bit register) to eax(32 bit register) is always faster than adding a memory address to a register respectively: add eax,ebx vs add eax,[ebx] the same goes for multiplication division and any comparison you can think of. and that is why they are faster but as I said. I am not familiar with the new architechture so I can't quote on that. |
| ||
| I would assume that, for most scenarios, working with less data is always going to be faster than working with more data (in the case of 64-bit integers, twice as much data). |
| ||
| yes but how about in a multiplication when two 32 bit values return a 64 bit value: mul eax,ebx returns the result in two registers. I believe it to be in ecx and eax or is it edx. can't remember for shure correct my anybody if I am wrong. and how about ax(16 bit register), al(8 bit register) ah(8 bit register) would you assume they are faster? they are not. eax(32 bit register) is faster than ax(16 bit register) and ax is faster than al(8 bit register) or ah(8 bit register) so why shouldn't a 64 bit register be any faster). That gentlemen is the problem. I am almost shure that when Mark wrote his compiler he did it on the basis of a 32 bit arch which was the norm at the time and that is why integers are faster for bmax and compilers previous to 64 bit arch. although if bmax goes to 64 bit arch. and logic serves me wright then the current size of long would have to become integers????? :) |
| ||
| It USED to be the case that accessing bytes would be faster than accessing integers, but that was when a) there was much less cache, b) cpu speeds were really slow, and c) memory speeds were really slow. These days, architectures are designed to be specifically more optimized for a 32-bit operation and it takes `extra processing` to narrow it down to a byte. Like I said, accessing integers from memory is faster than bytes, despite being 1/4 the amount. It doesn't seem like it make sense but that's just how cpu's work nowadays. And I agree, probably the Blitz compiler is just not a true 64-bit application and probably handles Longs as two separate integers glued together. I was hoping longs would be faster too, especially for moving large amounts of memory, but they're not. |
| ||
| probably the Blitz compiler is just not a true 64-bit application and probably handles Longs as two separate integers glued together All of the blitz products are 32-bit -- no 64 bit versions, and they don't create 64-bit executables either. Which is a bit unfortunate, since the market is slowly moving towards 64 bit operating systems now, being able to create native 64-bit executables (in addition to the current 32 bit versions) would be a major plus... :-? |
   |