I am setting up my InstallShield to install my package as 64 bit (into Program Files not Program Files x86) by.
My processor is: Intel(R) Core(TM) i7-2600 CPU
InstallShield => General Information => Summary Information Stream => Template Summary
From Intel32;1033 to Intel64;1033
And it gives me the general error message:
This installation package is not supported by this processor
Then I set the value to:
Amd64;1033 or x64;1033
And it magically work.
But weird thing is, my processor is Intel, how come it work for Amd64? But not Intel64?
So..... I have been reading this , this and this.
Obviously Amd64 was referred as x86-64 or x86_64 or Amd64, the 64 bit version of x86-instruction set.
Then Intel take the IA and called it Intel64.
So, then.... why wouldn't my Intel Processor not work with Intel64 but with Amd64?
The platform token Intel64 refers to the Itanium architecture. Modern 64-bit processors from both AMD and Intel aren't Itanium; instead they are the architecture collectively known as AMD64 or x64. These two architectures are not related, so code for one will not run on the other.
Related
I have a Laptop with Intel(R) HD Graphics 520 GPU in it. I added OpenCL developer package to Cygwin. I have found a small Mandelbrot-set calculator program for OpenCL in C on GitHub. It is for Apple, so I modified the Makefile to use the proper headers and settings for gcc. Now the code compiles and executes nicely (bmp file created):
$ ./mandelbrot.exe
Device 0: GenuineIntel pthread-Intel(R) Core(TM) i5-6300U CPU # 2.40GHz
I have two questions:
#1. How can I add (if it is possible) the Intel GPU to the /etc/OpenCL/vendors list? I tried to install from Intel site the Intel CPU runtime for OpenCL Applications for Windows OS and Intel Graphics Technology driver package, but I do not know where can I find the proper OpenCL dll I can point in the intel.idc file.
#2. In /etc/OpenCL/vendors I have found a pocl.icd file pointing to cygpocl-2.dll. I assume this is the pthread library. But it seems to me it is running only a single thread, although I have 4 cores. Should I do any modification to run it in multiple threads? I debugged the code and it seems that as there are only one device found, so it runs only on one thread. In the initialization function it sets the device_work_size property for processing a stirp per device of the final bmp. But as there is only one device, the whole bmp is processed by one run (one clEnqueueNDRangeKernel and one clEnqueueReadBuffer is called).
UPDATE
I have installed Intel(R) Graphics – Windows* DCH Drivers. It installed graphics drivers. I have found the intelocl64.dll (as /cygdrive/c/Program Files (x86)/Common Files/Intel/Shared Libraries/intel64/intelocl64.dll). I put this whole path into /etc/OpenCL/vendors/intel.icd file. So far, so good. Now it cannot even find pthread device... Bah...
I don't think it is possible to use the GPU from cygwin. I would recommend to either build a native Windows binary (e.g. with Visual Studio or Intel DPC++) or use WSL. See https://github.com/intel/compute-runtime/blob/master/WSL.md for requirements.
This question already has answers here:
Why can an executable run on both Intel and AMD processors?
(2 answers)
Closed 2 years ago.
I hope this isn't the dumbest question ever, but on my journey to learning about creating an OS, I thought about this and no amount of research is getting me anywhere.
How is it, when you install Windows on your computer, it just works, regardless of the underlying processor?
Let's say you have a 32-bit copy of Windows. How is it able to be run on every 32-bit CPU if the architecture is different per CPU? I see alot of resources saying bootloaders (where your OS starts booting), are written in assembly (which is tied to your processor instruction set). In that case, why is a Windows 32-bit OS able to run on Intel x86 as well as AMD?
For example, if I wrote a bootloader in x86, I can eventually make an ISO and boot it as my "primary" OS. But wouldn't that be tied to the CPU I wrote it for? So if I was a big company, how would I make my bootloader work for other CPUs?
Thanks! Sorry if it's a vague or repeated question, but I honestly could not find the answer.
"32 bit Windows" only runs on PC's with X86 32 bit processors. Windows includes drivers for various motherboards and devices, and can install drivers from CD or USB for devices not already supported by drivers included with the Windows install.
Some versions of Windows can run on multiple platforms, but require a Windows built specifically for that platform. The most common case of this is current versions of Windows that are either 32 bit (runs on X86) or 64 bit (runs on X86 X64). Windows NT 4.0 has versions for Alpha, MiPs, PowerPCs and PCs in 32 bit mode. XP was the first Windows to have a X64 version, and it can also run on Itanium. Windows 10 has versions for ARMV7 and ARM64 in addition to its 32 bit (X86) and 64 bit (X86 X64) builds.
I was having a small task to find whether the system is 32-bit or 64-bit machine during installation?
I figured the way by getting the value of registry PROCESSOR_ARCHITECTURE located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\ folder but I was surprised to find that value was AMD64 but my processor was Intel64 Family 6 Model 23 Stepping 10, GenuineIntel?
So why AMD64 for Intel64 bit processor?
According to documentation The 64 bit extensions to the x86 architecture were invented and first implemented by AMD.
That's why you get AMD64 and also the registry key is PROCESSOR_ARCHITECTURE which tells the underlying architecture used by processor which is off course AMD64.
For information,
Intel laggards to the 64 bit architecture because they were hoping to transition away from x86 architecture and move towards IA64. IA64 already existed in the form of the Itanium and Intel was hoping to transition towards that. Despite being a far better and more efficient architecture, lacking the inherent design flaws of x86, it suffered through lack of compatibility and it never took off as excepted in the commercial space. AMD on other hand, effectively forced Intel's by introducing the Sledgehammer, which was effectively a 64bit chip based on the x86 architecture. Hence the name AMD64.
I am coming from windows development. I have known that a binary can either be a 32bit or 64bit. But not both. And also that on a 64bit platform I can run 32bit binary but not viceversa.
In mac I am seeing a combined architecture like i386 x86_64 which is a bit of surprise for me. Why and when exactly do we target an app on mac osx for this architecture , what is the benefit of this ? why not a 32bit only which per my understanding of windows can run on 32bit as well as 64bit ?
It's not that the code is compiled for a "mixed" architecture - it's just that it's compiled for multiple ones.
The reason for compiling it for both 32 and 64 bit is that 64-bit programs generally perform better on a 64-bit architecture (most modern Macs) than 32-bit ones.
What are the differences between compiling a Mac app in Xcode with the Active Architecture set to i386 vs x86_64 (chosen in the drop down at the top left of the main window)? In the Build settings for the project, the Architecture options are Standard (32/64-bit Universal), 32-bit Universal, and 64-bit Intel. Practically, what do these mean and how does one decide?
Assume one is targeting OS X 10.5 and above. I see in the Activity Monitor that compiling for x86_64 results in an app that uses more memory than one compiled for i386. What is the advantage? I know 64-bit is "the future", but given the higher memory usage, would it make sense to choose 32-bit ever?
32/64-bit Universal -- i386, x86_64, ppc
32-bit Universal -- i386, ppc
64-bit Intel -- 64 bit Intel only
ppc64 is no longer supported.
x86_64 binaries are faster for a number of reasons; faster ABI, more registers, on many (most & all new machines) machines the kernel is 64 bit & kernel calls are faster, etc.etc.etc...
While 64 bit has a bit of memory overhead directly related, generally, to how pointer heavy your app's data structures are, keep in mind that 32 bit applications drag in the 32 bit versions of all frameworks. If yours is the only 32 bit app on the system, it is going to incur a massive amount of overhead compare to the 64 bit version.
64 bit apps also enjoy the latest and greatest Objective-C ABI; synthesized ivars, non-fragile ivars, unified C++/ObjC exceptions, zero-cost #try blocks etc... and there are a number of optimizations that are only possible in 64 bit, too.
iOS apps need to run on many different architectures:
arm7: Used in the oldest iOS 7-supporting devices[32 bit]
arm7s: As used in iPhone 5 and 5C[32 bit]
arm64: For the 64-bit ARM processor in iPhone 5S[64 bit]
i386: For the 32-bit simulator
x86_64: Used in 64-bit simulator
Xcode basically emulates the environment of 32 bit or 64 bit based on what is set in the Valid Architecture - i386 or x86_64 respectively
Every architecture requires a different binary, and when you build an app Xcode will build the correct architecture for whatever you’re currently working with. For instance, if you’ve asked it to run in the simulator, then it’ll only build the i386 version (or x86_64 for 64-bit).
Unless you have a reason to compile for x86_64, I recommend just compiling for i386 (and PPC if you support that). Read Apple's stance on the matter:
Although 64-bit executables make it
easier for you to manage large data
sets (compared to memory mapping of
large files in a 32-bit application),
the use of 64-bit executables may
raise other issues. Therefore you
should transition your software to a
64-bit executable format only when the
64-bit environment offers a compelling
advantage for your specific purposes.