 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : integers and decimals
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i was just thinking about data types and came up with an interesting idea. i am not suggesting this is something to be added to MMbasic, but just want to kick around the idea and see what others think about it... instead of having integer and floating point (decimal) variables as different types, why not reserve one bit in the variable's data area to indicate the type? so you would then have space for 63-bit integers and 8-byte (minus 1 bit) decimals. the assumption here is that 63-bits for an integer variable is more than enough for almost any application. one up side of this idea would be that a more intuitive and simple syntax could be added to both assign and change the type of a variable on-the-fly: ABC = pi ' 3.14159 etc.
ABC = integer ' convert ABC into an integer (value = 3) print ABC ' prints out "3" ABC = decimal ABC = ABC + 0.5 print ABC ' prints out "3.5" DEF = 22 / 7 ' use of division creates a decimal print DEF% ' also prints "3", % is a temporary modifier integer GHI ' creates a variable as integer decimal JKL ' creates a variable as decimal if integer(GHI) print "GHI is an integer" if decimal(GHI) print "GHI is a decimal" where appropriate, functions could throw an error if the variable passed in was of the wrong type. for instance print sin(GHI) would generate an error, as would GHI = sin(pi). but print sin(GHI!) would be ok as ! is a temporary modifier that changes the type to decimal. note: the % and ! modifiers would do a genuine conversion, not just a C-style typecast. hence print ABC% could produce an overflow error if ABC held too high a value. this is all just a half-baked idea, but i would be interested in hearing feedback. cheers, rob :-) |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I personally like variable to be of a single type defined with a dim or local statement or by using the %!$ modifiers. It is one of the things i don't like in Javascript as it can cause unforeseen errors. I experimented a while ago with the following in C [code] typedef enum { VAL_FALSE, VAL_NULL, VAL_INTEGER, VAL_DOUBLE, VAL_TRUE, VAL_UNDEFINED, VAL_OBJ } ValueType; typedef struct { ValueType type; union { double d; int32 i; Obj* o; } as; } Value; [/code] The advantage of using int32 is that they can be used in registers and are lightning fast. 64 bits integers have overhead that slows things down a lot. Storing the type has a bit of overhead, a single byte is enough to store 256 different types which is more then enough. :) Also adding new types would be easy. I am using the above for my pic javascript interpreter which is just a side hobby and will probably take sometime before it is working properly. :) Microblocks. Build with logic. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
I am wondering why you would want to do that, ie, what is the benefit? I suppose that you could convert a number from float to int and reverse with a single command but that does not seem all that useful to me. I once saw a demo of an ancient IBM 1401 and that held numbers as BCD digits and it allocated as much memory as necessary to hold the number. The result was that you could have numbers that were hundreds of digits long with the decimal point placed anywhere. Now that was versatile - but slow. Geoff Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
The outcome would not be vastly different from what happens now but it would be slower. Whole numbers are already exact within a range. So, apart from it being slower and a different range, what would be the point... John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
microblocks: does going from 32-bit integers up to 64-bit integers on the PIC32 family introduce a significant speed penalty? is this evident given the other overheads of a BASIC interpreter? within the constraints of a BASIC-like interpreter running on a microcontroller, i can't see too many advantages in allowing for a great many variable types: string, decimal, integer covers most needs; byte would be nice but has the potential to add further complexity to the interpreter. geoff (and john): i'm mostly thinking about ways the syntax of BASIC could be made to look cleaner and be made to appear more 'meaningful', while not going overboard (like representing everything as arbitrary length strings with the associated memory-management nightmare). in terms of language functionality - the work a program can do - there would be no real advantage. i guess one could claw-back the lost bit by storing the 'type' flag in the high bit of the first character of the variable's name, or in the top bit of the address pointer. this gets one back up to 64-bit integers. btw: borland did release Turbo Pascal 3 (mid 1980s) in two flavours, regular and BCD. i'm guessing the idea was that the BCD version was more suited to scientific and financial calculations, but i don't recall it ever really taking off. by the time TP4 came out, the BCD version was gone. cheers, rob :-) |
||||
| Dylan Regular Member  Joined: 17/06/2013 Location: NetherlandsPosts: 81 |
Turbo Pascal 3 was there in a time that x87 coprocessors were rare. The 486 only came out in 1989. The 386 was the first 32-bit main processor from Intel. The ZX Spectrum had 5-byte numbers, which could either encode a 17 bit integer (with a -65536 issue) or a floating point number. I only have the ROM disassembly book, not the manual to hand, but the reason for this must have been that Z80 is only 16 bit native. To return to the OP, in an interpreted language having any kind of polymorphism whatsoever slows things down even more than usual AND takes more space in the very limited space a microcontroller has. |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
In electride I have char, string, byte, 16 and 32 bit integers, and 32 and 64 bit floats (doubles). In common with general computing the 64 bit floats do indeed take longer to crunch but otherwise the processor uses native 32-bit binary, so crunch time are similar, bogged down by parsing !!! The main advantage of bytes chars etc is that they take less space and can, eg, be stored or transferred in bulk via dma etc. Adding different datatypes does add to the overall time taken a little but as rob points out above it is not very significant when the main overhead is the interpreter. (ed) I gather the Arduino platform has a "BigNumber" library added to enable large numbers, but the resource cost restricts it to higher spec variants (?) |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
