NOD32 for Win x64-wrong...:-P

Discussion in 'NOD32 version 2 Forum' started by iNsuRRecTioN, Jun 24, 2005.

Thread Status:
Not open for further replies.
  1. iNsuRRecTioN

    iNsuRRecTioN Registered Member

    Joined:
    Sep 5, 2003
    Posts:
    303
    Location:
    Germany
    Hi there,

    why Eset name the new 64 bit Edition of NOD, NOD32 for Windows x64 and not NOD64 :p

    I thought the "32" value in the NOD32 name stands for 32 bit and so, NOD for 64 bit have to be named NOD64, IMHO ;-)

    best regards,

    iNsuRRecTiON
     
  2. alglove

    alglove Registered Member

    Joined:
    Jan 17, 2005
    Posts:
    904
    Location:
    Houston, Texas, USA
    Because then people would get it mixed up with the Nintendo 64?
     
  3. Blackspear

    Blackspear Global Moderator

    Joined:
    Dec 2, 2002
    Posts:
    15,115
    Location:
    Gold Coast, Queensland, Australia
    It would be like McDonalds changing the name of its BigMac to littleMac if they brought out a bigger version. It's all about marketing.

    Cheers :D
     
  4. PLeX?

    PLeX? Registered Member

    Joined:
    Aug 28, 2004
    Posts:
    28
    Location:
    Knoxville, TN USA
    Probably because Windows XP Professional x64 Edition is not truly a 64-bit operating system.
     
  5. iNsuRRecTioN

    iNsuRRecTioN Registered Member

    Joined:
    Sep 5, 2003
    Posts:
    303
    Location:
    Germany
    Hey,

    ooh, wow, one good and useful answer, the others are crap..

    best regards,

    iNsuRRecTiON
     
  6. jeh

    jeh Registered Member

    Joined:
    Jun 25, 2005
    Posts:
    4
    Actually, yes, it is. I'm curious -- what leads you to believe otherwise?
     
  7. PLeX?

    PLeX? Registered Member

    Joined:
    Aug 28, 2004
    Posts:
    28
    Location:
    Knoxville, TN USA
    Not only is x64 not a true 64-bit OS, the AMD64 and EMT64 aren't true 64-bit processors. They only allow x86 to use 64-bit registers so that a system can have and use more than 4GB of RAM in a emulated 64-bit system (previously a technology called PAE was used to allow Windows to break the 4GB barrier but at quite a performance cost). A true 64-bit OS would need all new hardware which noone seems to want to buy so we are stuck with this workaround. Eventually an Itanium-like processor with IA64 will be able to emulate x86 fast enough to run legacy apps in a virtual machine that will make most happy and we will be able to move into true 64-bit computing. Until then, we get to live in a "64-bit" dream world hyped by AMD, Microsoft and Intel (the latter doing so reluctantly). Sadly, most everyone is falling for it, which means the transition from 30 year old x86 will continue much longer than it should.

    Don't get me wrong, x64 and Server 2003 64-bit are great ideas for high-end workstations and servers needing more than 4GB of RAM (sure beats PAE in performance). But thats where it should stop.
     
  8. jeh

    jeh Registered Member

    Joined:
    Jun 25, 2005
    Posts:
    4
    Sorry, but this is one of those popular bits of FUD that's been floating around recently.

    I'm a kernel driver developer and seminar leader in this field; I've spent much of my professional life in the last year and a half helping people port their drivers to these machines, debug them, etc. And anyone who's spent more than two minutes looking at the disassembly code in the debugger, let alone writing the odd bit of assembly code, will see that AMD64 and em64t do offer true 64-bit environments:

    - Virtual addresses are extended to 64 bits. (This is far more important than RAM addresses, by the way. Damned annoying to deal with in the debugger too.)

    - All general purpose integer registers are now 64 bits wide... NOT just for purposes of addressing memory, but also for integer arithmetic. All basic logical and arithmetic operations can now be done on 64-bit ints and unsigned ints. Just like on ia64.

    - Speaking of general purpose registers, under x64's "long mode" there are twice as many of them. Again, this is not just widening the registers.

    - Data paths to memory are at least 64 bits wide (as they have been on x86 environments for some time). This is really more a function of the memory controller than the CPU core, and if you ran the memory bus fast enough this really wouldn't matter... but there it is.

    - Under Windows XP X64, all pointers returned by and passed to system calls (everything from the long mode version of malloc to MmGetSystemAddressForMdlSafe) are 64 bits, as are the size arguments for most allocations. And I can have processes that use more than 4 GB virtual address space. LOTS more. The current implementation limit is 8 TiB; when that becomes a limiting factor it'll be trivial to move the boundary.

    This makes it a true 64-bit environment by any reasonable definition.

    Yes, it supports 32-bit apps under the 64-bit OS, but that doesn't make it "not a true 64-bit environment". Is x86 not a "true 32 bit environment" because we can, if we want, address only 16-bit pieces of the GPRs and run DOS apps under NTVDM? Was the VAX not a "true 32 bit processor" because it included a 16-bit compatibility mode under which it could directly execute PDP-11 programs? Is it really a requirement to make up an entirely new instruction set, and abandon direct execution of legacy apps, before people will stop saying "not a true 64-bit CPU"?

    It isn't truly a new instruction set, that's for sure! But, that's a different question.

    By the way, I have no idea how Linux or anyone else will handle it... but under Windows, the 32-bit compatibility mode is strictly for user mode -- all kernel mode code (ring 0) is 64-bit. 64-bit pointers, 64-bit general purpose (integer arithmetic) registers, etc. This is why everyone has to port their drivers.

    All new hardware? If you want. For example, it would be possible to put together an amd64 or em64t motherboard with only 64-bit PCI-X slots. But the CPUs qualify as "true 64-bit" already.

    By the way, the width of the machine's registers (other than CR3) has NOTHING to do with RAM addresses. RAM addresses come out of page table entries, not registers.

    And PAE is nowhere near as bad as many people believe. Forget anything you've read about PAE "paging things in and out of the lower 4GB" - that's just more FUD. It's just address translation as usual... but with three levels of page table lookup instead of the usual two under x86. The additional overhead is only incurred when you have a miss in the TLB, and it is usually more than made up for by extending RAM from say 4 to 8 GB, in environments that need it.

    In fact, if 64 bits were only about increasing RAM size, there'd be NO reason for x64, as the way X64 supports large amounts of RAM is very much like PAE, just more so! PAE changes from x86's normal two-stage page table lookup to three stages; x64 uses four-stage lookup. And don't think Itanium will save you from that, because it does the same thing yet again, with a three-stage lookup just like x86 PAE!

    I know this sounds expensive -- worst case, you have to do three memory fetches (four on x64) before you can do the memory reference you wanted to do in the first place -- but with these very large virtual address spaces, the alternative of very large virtually contiguous page tables would be even more costly. Both families make up for this by increasing the size of the TLB, which gets the address translation overhead back down into the range where it normally is on x86.

    obtw, when you boot XP SP2 on a machine that supports /noexecute, you're running in PAE mode, even though XP won't let you use more than 4 GB RAM. It's necessary because there's just no place in a 32-bit page table entry for the no-execute bit. PAE makes room for that bit along with the additional bits of physical address.
     
    Last edited: Jun 26, 2005
  9. beetlejuice69

    beetlejuice69 Registered Member

    Joined:
    Mar 16, 2005
    Posts:
    780
    Very good read and very informative, thanks.


    Oh, we`re still not gonna call NOD32 NOD64 though. :)
     
  10. Firecat

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    7,927
    Location:
    The land of no identity :D
    I shall stick to calling the x64 version NOD32 DDR :D:D
     
  11. jeh

    jeh Registered Member

    Joined:
    Jun 25, 2005
    Posts:
    4
    Just, please, don't call it NOD32 XTREME EDITION!!! :D

    /me remembers when every other software product was called "Turbo" something or other, and shudders
     
  12. iNsuRRecTioN

    iNsuRRecTioN Registered Member

    Joined:
    Sep 5, 2003
    Posts:
    303
    Location:
    Germany
    Hey,

    yeah, a very thanks for this from me to you, jeh, too.

    So what is about that Eset?

    Any mod, admin, coder/programmer at Eset, please reply, thx.

    best regards,

    iNsuRRecTiON

    btw. you can implement support for SMT/SMP for/in NOD64 e.g. for DualCore or Hyperthreading and improve it on that platform, too :p
     
  13. jeh

    jeh Registered Member

    Joined:
    Jun 25, 2005
    Posts:
    4
    Regardless of what it's called, the developers deserve kudos for getting an x64 version out and supported! If keeping the name the same helped that happen faster, that's a good thing.
     
  14. Firecat

    Firecat Registered Member

    Joined:
    Jan 2, 2005
    Posts:
    7,927
    Location:
    The land of no identity :D
    NOD32 is coded in assembly, which is extremely fast and probably the fastest developer language. As far as I know, there is no way to optimize assembly code for specific CPUs.
     
Thread Status:
Not open for further replies.