Query: I'm interested in whether or not there is a known manner to 'create' a datatype akin to int, but instead of a constant size, it may be altered, yet still run seamlessly with any code using the variable. The only way I could think would be to use a pointer and memset, but this seems like it would be a bit bulky/slow. Besides, if you were to rely on a pointer, then I fail to see how you could have a pointer of n-bitness. (You can't use a pointer to n-bit memory as a pointer itself, can you? o.O) If there is some near-seamless way to do this, is it going to be a major performance hit? i.e., not something you'd want to use for an operating system or something else that will affect the speed of the other programs? Hope I stated my question clearly enough. :/ Thanks! (Note: n-bitness can be limited to n=2^(some real number) for the purpose of my inquery.) (NoteNote: Also, this is in regards to assembly/C/C++ for the most part.)

Sure:


Although, that requires Python...

You allocate memory in 32-bit chunks (or ints) for 32-bit architecture, or 64-bit chunks for 64-bit architectures. This allows for pretty fast operations (addition of two ints will result in one bit overflow, which you then apply to next chunk in sequence). Multiplication, and other operations are trickier.

Then it's just a matter of implementing (overloading) the operators to do what you want.

Although I can't think of one, I'm sure there's a library that does that somewhere out there.

In assembly, many of these operations can be implemented quite efficiently, but you still lose the benefit of passing values through registers, and for most part need to allocate them on heap to be dynamic. So while there is a penalty hit, it's not that drastic (but there is - so you don't want to replace primitive types with such implementation)

But are the GNU addon and BigNumber "self-sufficient", i.e., they could be run on a machine that didn't have *any* libraries or functions (for lack of a better example, could they be used in the source for an OS)?

Thanks!

Quote:Original post by nerd_boy
But are the GNU addon and BigNumber "self-sufficient", i.e., they could be run on a machine that didn't have *any* libraries or functions (for lack of a better example, could they be used in the source for an OS)?

Thanks!

Provided you have access to operator new, or malloc, yes.

Quote:Original post by ravyne2001
What exactly is your reason for needing this behavior? If you hope to save memory, it will likely only help if you have a dataset that is mostly small, but with sparse, very large items.

There are a few. Mostly mathematically related. i.e., a library on an OS that is '8-bit by default' possibly still being capable of 64-bit int math or 256-bit float math (I'm sure this is rather large, but just making a point), etc.

Another reason depends on my learning a bit more about hardware. Say we had a machine with an OS that is "limited" to, again, 8-bits by default could access, say, an external harddrive that requires 32 or even 64 bits to access all of its contents. If the local hardware is responsible for addressing of the external, then I doubt one could use any of these methods to access the entire thing. If its just a matter of data sent, however, I'm hoping one might be able to send, for example, the 32-bits as 4 seperate 8-bits, etc.

I'm probably wrong on the last one, so I guess mostly for mathematics, etc.

Quote:Original post by nerd_boyAnother reason depends on my learning a bit more about hardware. Say we had a machine with an OS that is "limited" to, again, 8-bits by default could access, say, an external harddrive that requires 32 or even 64 bits to access all of its contents. If the local hardware is responsible for addressing of the external, then I doubt one could use any of these methods to access the entire thing. If its just a matter of data sent, however, I'm hoping one might be able to send, for example, the 32-bits as 4 seperate 8-bits, etc.

I'm probably wrong on the last one, so I guess mostly for mathematics, etc.

Hardware implications of small data types are much more drastic, and people are very happy we no longer work in 8-bit world (processors, let alone addressable memory).

The problems with hardware compatibilities you mention are considerably more drastic than just that. It's not a matter of coding something that serves as represenation in memory (32-bit addressing on drives is long gone history - that's only 4 gigabytes).

And let's not forget the joys of A20 line, and other horrors with regard to memory.

Math isn't the problem there - devices that can't address large types directly can't do so through code hacks, they require proprietary approaches. For example, segment:offset notation where mappings between addresses aren't linear. Let alone when hardware is involved, where you might need to trigger interrupts to select the memory bank you want fill (VESA high-resolution graphics comes to mind with frame buffers), and all other hacks.

Large numbers are used for certain narrow domains, such as cryptography, finances, and possibly a few more.

But as it stands, performance is rarely an issue there. And if it is, it's done with native types, and compensating for artifacts that arise.

Also remember, that integers have extremely limited uses. While fractional representation of numbers will get you a bit further - how many bits does the value of Pi take?

Instruction sets are often designed with the capacity for integers greater than the register or word size in mind. The common approach is to have versions of the arithmetic operations that are designed to work with a set of flags. An add with carry operation can be used to add together larger integers. First the lowest bits of the numbers are added, and if there is an overflow then the carry flag is set. Now the next lowest bits are added, and if the carry flag was set then an extra 1 is added to them, the carry flag is set to indicate if there was an overflow or not, and so on up to whatever size number you're using. With 32 bit adds, you could add together two 64 bit numbers with just two instructions (not including the instructions needed to load them into registers).