I have always used windows and have been using ifort (openmp type codes) for the past 10 years.
That means that I have a lot of legacy code that has been run using ifort (using OneApi more recently).
I am planning to switch from windows to mac.
It seems that there are compilers for mac. The question is should I expect all my legacy code either not to run, or if it runs for the results to be different given the different compilers?
How much of an headache is the switch going to be?
Is installing parallels and windows and then oneapi on a mac feasible?
I suggest installing gfortran on Windows and comparing the results of your programs compiled with gfortran and Intel Fortran. Also try compiling your codes with Intel Fortran with a standard-conformance option such as /stand:f2018. That will be more informative than someone speculating about code they have not seen. When moving from Windows to a flavor of Unix, a program may fail if file names are not capitalized consistently (Windows file names are case-insensitive, unlike Unix file names) or if the Windows directory separator is hard-coded.
In my experience, Intel has always been one of the most “forgiving” compilers, letting users unwittingly rely on non-standard extensions and behaviors. Not to say that you will have a lot, or even any, portability issues, but I wouldn’t be surprised if you find at least a few. Good luck trying though, as it is something worth at least knowing about.
On MacOS, the filename sensitivity depends on the file system, not the OS. You will have the option to set up a case insensitive file system or a case sensitive file system within each disk partition/container. The former acts like Windows while the latter acts like a typical unix/linux/posix file system. On MacOS, I typically set up my $HOME directory to be case insensitive and I have various other partitions installed that are case sensitive (just in case I inherit come linux code that uses that feature). In my own development work, I try to use file name conventions that work both ways.
Mac computers have used a variety of cpus over time, from Motorola cpus in the 1980s, to PowerPC cpus in the 1990s, to intel cpus in the 2000s, to ARM cpus now. I think all of these have been little-endian machines, so that aspect should not be a problem. [edit: This statement is corrected below. The Motorola and PowerPC Macs were big-endian.] Also, surprisingly, I have found for the most part that unformatted fortran files with one OS+hardware+compiler combination work with other combinations, so hopefully that will not be a problem either. However, not all compilers work on all hardware combinations, so you may need to search ahead of time to see what compilers will work for your codes at the present time. Gfortran, for example, works on both intel and ARM Macs, so that might be the path of least resistance to porting codes if you are switching to ARM hardware.
Of course, if your codes are written in a portable way, then that will make the transition easier too.
Motorola 68k cpus were big endian, actually. PPCs were bi-endian, but were used as big endian in the Mac’s. But yeah, the Mac’s have been little endian for almost 20 years now.
I don’t expect too many difficulties, unless your codes use some libraries that are specific to Intel and/or Windows.
In short: no.
The ARM version of Windows is not sold separately, it is only available as preinstalled on some ARM PCs. And even if it was, there’s no Windows ARM version of the Intel compiler either.
What is possible is to install the x86 version of Windows in an emulator, and then the Intel compilers can be installed (although not officially supported by Intel). But this would be damn slow…