C++ improvement

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.

Bitset

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.

>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).

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.