A popular topic on this board is what will replace C++. People list all kinds of ideas and junnk of a language that will replace it. Maybe have it to where you can work with numbers on the binary level, and allowing use of custom sized variables, like maybe being able to make a variable with a specified number of bits to represent it or something.
>make a variable with a specified number of bits to represent it or something.
that might be nice in some respects, but it would actually be slower than fixed-bit variable types.
32-bit processors work fastest with 32-bit data types. they can manipulate them quickly and easily.
64-bit proessors work fastest with 64-bit data types, and the same goes for 16-bit processors, etc...
Besides even if we did have variable-bit data types, they would still be referred to the same way in memory as normal data types.
For example, the x86 architecture is "byte-addressible". Therefore, even if I created a data type that uses 5-bits per instance of that type, it would probably just be considered an 8-bit data type on the x86. it is byte-addressible and would take up one memory address.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
Not to mention that you'd have to completely rewrite the entire x86 instruction set to deal with the new sizes or new type. Not a good idea. The only way to do that would be to declare a variant type in asm but then the CPU would not have any idea how to fetch the sucker unless it read some sort of header prior to the variable which would be a heck of a lot slower than current designs.
It wouldn't have to be a change in machine architecture. It could be a higher level change (which would of course be slower)... like bitset.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
>It wouldn't have to be a change in machine architecture
Maybe not if you wanted the language to be an incredibly slow language.
He is talking about an entire language being bit-accessible, not just some class.
Even with a change in the microarchitecture, it will still be slower than any language we have now.
Bubba is right. Each variable would have to have some type of header for the cpu to know how to do a fetch from memory, otherwise it wont know how to get data, because all data is a variable amount of bits.
With a language like that....the term "memory address" would become non-existent almost, which would be a bad thing.
The other option would be to change the architecture to give each bit it's own address. Dealing with arbitrary size types would then be much easier. It would, however, be much slower, so a software implementation seems to be just as good (with the added benefit that you don't actually need to design a new architecture).
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
One thing that would speed up current designs is to use RISC more than CISC.
Also if you could load segment registers with descriptors w/o having to use LES LDS LFS LGS etc -
mov es,[Source]
Opcodes like this. This would be about as fast as
LES EDI,dword ptr [ptr32]
The biggest improvement to the x86 design would probably be to design the MOV instruction with RISC architecture rather than CISC. For instance if a mov only took say 1 cycle instead of 3 or 4 (depending upon usage) a program that had 40000 mov's would execute in 40000 cycles instead of 120000 or 160000.
Also if more opcodes were SIMD based like MMX and SSE2 then the system would speed up a lot. Also if MMX could do memory to memory transfers you could do this much faster:
Code:;Additive color blending ;Adds Picture1 to screen image ;save ds push ds ;load ds:esi with picture lds esi,[Picture1] ;load es:edi with Screen les edi,[Screen] ;load ecx with number of QWORDS in image mov ecx,[size_in_bytes] shr ecx,3 ;convert bytes to QWORDS START: ;transfer 64 bits from image to MMX register 0 movq MM0,[ds:esi] ;perform packed add paddd MM0,[es:edi] ;transfer 64-bits of last op back to screen movq [es:edi],MM0 ;increment edi by one QWORD add edi,8 ;increment edi by one QWORD add esi,8 ;decrement ecx by 1 QWORD sub ecx,1 ;loop to START while ecx>0 loop START ;clean up pop ds
Also there is not a packed add with saturation for DWORDs or QWORDs which would help a lot. This is not a packed add with saturation so the data type will wrap around when the bytes reach 0FFh which could cause a problem. There is a workaround via another MMX opcode but I did not implement it.
So if a memory to memory transfer was allowed - I could simply add pic1 to image1 and then blit the result.
But using MMX this operation is still blazing fast for software implementations w/o using a 3D accelerator.
