How to know your assembly language when you know your processor version?
Example: my processor version is Intel(R) Core(TM) i3-2350M CPU # 2.30GHz
The "assembly language" is not influenced by the particular model of processor; in your case; you want an assembler for Intel x86-64.
There may be model-to-model variations on what instructions are supported; Intel provides data sheets that tell you that for each processor. Alternatively, you can glean the info from Wikipedia.
Finally, there may be a choice of assemblers. There is one from Intel and one from the GNU project. The instruction syntax (i.e., the "assembly language") is very different between those two, for the same set of machine instructions.
Related
I want to write a parser for Intel x86 assembly, say NASM, to break the instructions up into basic blocks.
In order to do this correctly, I need to know all control flow instructions.
I am well aware of all the jmp, jne, jle, etc. instructions, but are there others beside those “common” ones?
You know, haswell is the codename for a processor microarchitecture developed by Intel as the "fourth-generation core" successor to the Ivy Bridge microarchitecture.1 Intel officially announced CPUs based on this microarchitecture... More
But, I want to know how to show's up my CPU if haswell or not by using the PowerShell in windows?
in this case i have a script to to that, but it maybe not legal for everyone:
$cpuname = (Get-CimInstance CIM_Processor).Name
$splcpuall = #($cpuname -csplit "")
$splcpu = $splcpuall[20]
$ishaswell = if ($splcpu -gt 3){
Write-Output "Haswell"
}
Identifying a CPU needs some digging and regular maintenance for new CPU models is needed too. Your best bet is to use some existing tool that provides CPU information. For example, CPU-Z is nice a tool.
The problem is that CPUs don't contain human readable name strings. What they contain is a CPUID, a hex code that must be looked up and interpreted as model name. Hashwell's ID is 0x0306C3, Broadwell's is 0x0306D4 and so on.
Digging up the CPUID can be done via WMI. On a Broadwell box:
(gwmi win32_processor).ProcessorId
BFEBFBFF000306D4
The result is a string combination that contains stuff in addition to the CPU ID. This needs to be parsed to identify the CPU ID part and then the matched name must be looked up from somewhere.
It seems like the docs: https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/i386-and-x86_002d64-Options.html are somehow incomplete of the options for -march=XXX (and -mtune=XXX), what are all the possible options?
OK found an updated list, google doesn't take you there, you have to manually find it: https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/x86-Options.html#x86-Options
Appears the list is:
32-bit processors:
athlon
athlon-4
athlon-fx
athlon-mp
athlon-tbird
athlon-xp
k6
k6-2
k6-3
geode
c3
c3-2
winchip-c6
winchip2
i386
i486
i586
i686
pentium
pentium-m
pentium-mmx
pentium2
pentium3
pentium3m
pentium4
pentium4m
pentiumpro
prescott
lakemont
64 bit processors: (note that you can use this as march and mtune values for 32-bit compilers, as well).
amdfam10
athlon64
athlon64-sse3
barcelona
bdver1
bdver2
bdver3
bdver4
znver1
btver1
btver2
k8
k8-sse3
opteron
opteron-sse3
nocona
core2
corei7
corei7-avx
core-avx-i
core-avx2
atom
slm
nehalem
westmere
sandybridge
ivybridge
haswell
broadwell
bonnell
silvermont
knl
skylake-avx512
x86-64 # this is some kind of "generic 64 bit" option apparently
And a few exceptions: -mtune can also have -mtune=generic and -march can have -march=native (native meaning "the same as the compiler box it is being built on")
refs:
https://github.com/gcc-mirror/gcc/blob/21ecea397b2b4725f89d1693aaa6df74d3dcfa27/gcc/config.gcc#L587
https://github.com/gcc-mirror/gcc/blob/c7f16cfa30360489a9d42e244cb800c7da0396d9/gcc/config/i386/i386.h#L334
https://github.com/pixelb/scripts/blob/master/scripts/gcccpuopt
You can also visit the documentation of the latest version of GCC, which can be found here.
This is a community wiki, feel free to add any that come up later, and or add explanations of what these each mean, if there are any equivalence classes, etc.
I have read article of Duartes from: http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory
In part that describes about PTE content, bit [0:11] is different with description in ARMv5 Architecture Reference Manual
Detail is:
Bit [0:11] of the PTE contain:
In Duartes article: bit 0: P (present), bit 1: R/W , bit 2: U/S (user/supervisor),...
In ARMv5 Architecture Reference Manual : Bits[1:0] Identify the type of descriptor (0b11 marks a fine page table descriptor), Bits[4:2]: The meaning of these bits is IMPLEMENTATION DEFINED,...
(Refer at: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/I16780.html ) . I think the Second-level descriptor in ARMv5 Architecture Reference Manual is corresponding with PTE in Duartes's article.
So, question is the PTE descriptor is depending on platform (x86, ARM,...) ?.
For me, I think PTE descriptor should not depend on platform.
Thanks
As each architecture implement their MMU (memory management unit) differently, the PTE descriptor is architecture dependent.
If we look at Linux, it has a three level page table structure (inherited from the x86 architecture), which in most ARM platforms is wrapped to fit a two level page table structure (newer ARM have support for 3 levels). Linux also uses "dirty" and "accessed" bit that is available in the x86 architecture for the memory management logic of the kernel. These bits are not available in the ARM architecture, which ARM Linux has solved by emulating it in software. This is done by having two versions of the PTE page tables. One for the OS which contains these missing "bits", and one for the actual HW to use.
In the end, the Linux OS for different architectures behave the same. It's all about how the OS are using the hardware mechanisms that the specific architecture is offering as there are pro and cons for each.
The ARM Linux code is different depending on the type of ARM and other conditionals. pgtable.h, page.h and mostly pgtable-2level.h give some details. There are two versions of PTE values; one for Linux and one for hardware.
I am trying to build a cross compiler to target the processor running on my NAS box using crosstool-NG.
The NAS box is a ZyXEL NSA210, there is an example dmesg output, the /proc/cpuinfo is:
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 183.09
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
...
Hardware : Oxsemi NAS
Revision : 0000
Serial : 00000d51caab2d00
The options on the target options page, the flag and my current settings in ():
Target Architecture (arm)
Use the MMU (yes)
Endianness (Little endian)
Bitness (32-bit)
Default instruction set mode (arm)
Use EABI (yes)
Architecture level --with-arch= ()
Emit assembly for CPU --with-cpu= ()
Tune for CPU ()
Use specific FPU ()
Floating point (software)
Target CFLAGS ()
Target LDFLAGS ()
I've been trying various combinations in the 'Architecture level' and 'Emit assembly for CPU', such as arm926ej-s, armv5l, armv5tej, but I don't know which option goes where.
I've set the Target OS to bare-metal as crosstool-NG doesn't have the version of Linux used on the box.
Also, once the toolchain is built do I need to pass the same options again to the compilers.
So far by attempts have just produced the Illegal instruction message.
Edit
If anyone could point me towards an article on setting up an ARM GCC toolchain with explicit reference of how to find out the correct parameters, that would answer my question.
Try one of these
--with-arch=armv5te
--with-tune=arm926ej-s
or
--with-cpu=arm926ej-s
(there's no point in having both).
Otherwise your options look fine.
If it still doesn't work then you need to look at the libraries and headers. If you want to use dynamically linked libraries then you'll need to have ones that match those on the target, version wise and name wise. If you want to use static linking, or copy your own shared libraries onto the target (in a non-standard place, perhaps, which would need extra config), you should be fine.
Either way, you'll need your kernel headers to match. You can probably just download some contemporary kernel headers from kernel.org.