C++ improvement

This is a discussion on C++ improvement within the A Brief History of Cprogramming.com forums, part of the Community Boards category; A popular topic on this board is what will replace C++. People list all kinds of ideas and junnk of ...

  1. #1
    Banned frenchfry164's Avatar
    Join Date
    Oct 2001
    Posts
    1,552

    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.

  2. #2
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,738
    >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.
    My Website

    "Circular logic is good because it is."

  3. #3
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    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.

  4. #4
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

  5. #5
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    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.

  6. #6
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,738
    >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.
    My Website

    "Circular logic is good because it is."

  7. #7
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    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.

  8. #8
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. First Program - would like improvement suggestions
    By Venicia in forum C++ Programming
    Replies: 2
    Last Post: 05-24-2007, 10:53 AM
  2. An improvement for the board...
    By Queatrix in forum A Brief History of Cprogramming.com
    Replies: 37
    Last Post: 09-19-2006, 06:32 PM
  3. code improvement before i go further!!
    By samirself in forum C Programming
    Replies: 2
    Last Post: 06-25-2005, 12:52 AM
  4. Code improvement suggestions
    By Xzyx987X in forum C Programming
    Replies: 16
    Last Post: 03-26-2004, 12:03 PM
  5. Howz this for improvement!
    By cyberCLoWn in forum C++ Programming
    Replies: 5
    Last Post: 01-18-2004, 06:58 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21