曾几何时，网络处理器是高性能的代名词。为数众多的核心，强大的转发能力，定制的总线拓扑，专用的的指令和微结构，许多优秀设计思想沿用至今。Tilera，Freescale，Netlogic，Cavium，Marvell各显神通。但是到了2018年，这些公司却大多被收购，新闻上也不见了他们的身影，倒是交换芯片时不时冒出一些新秀。
你可以在网上搜索Cortex-A57 Software Optimization Guide， 这里面会有指令timing的信息。
2） For Microsoft compiler, it also supports below grammar:
两条指令之所以安排他们同时执行，就是因为两条指令同时的执行时间小于二者之和啊。应该说，和最长的那条指令执行时间一样长——你会发现，双发射的流水线连回答“他的执行时间与一条指令单独执行相比如何？”都是不容易做到的。
操作系统类型和版本main 父进程的子线程数量、优先级UDP 所在的 thread 线程的共享地址空间的设定、优先级等一般而言，进程（process) 和 线程（thread) 的 performance 会有一些区别，这由他们不同的本质导致的。受影响的因素较多，很难用一句话简单回答根本原因是什么。
可以使用硬件终端或者SMC指令，例如在ARMv时，一般在FIQ作为secure 中断，FIQ的优先级比IRQ要高，可以通过SCR.IRQ和SCR.FIQ bits控制对应中断被taken到Monitor mode. 在ARMv8略有不同，FIQ不再有快速中断的意思，但是也可以SCR_EL3来控制中断，具体如何使用也跟software的设计和使用的GIC有关，建议看下下面这个链接
应用程序在使用OpenGL ES等API的时候，会同时消耗CPU和GPU。如果API或者下发任务的次数增加，会增加CPU的消耗时间。如果改变定点数或者改变vs，fs，则更多影响的是GPU的荷载。关于应用程序的优化，在[链接] 可以有一些文档或者资料怎么在Mali上写出更优的应用程序。
Mali的硬件有提供丰富的硬件参数，但是需要专业的工具比如DS-5才能看到这些结果，同事也需要对系统做特殊的编译。要理解这些参数也需要对GPU的硬件有一定的了解。
Mali T760支持OpenGLES、OpenCL、Vulkan等标准的API接口，应用开发者可以调用这些标准的API接口来使用GPU的硬件加速。具体的API文档可以在[链接] 上面下载到。
ARM有篇文档叫Trusted Board Boot Requirements(TBBR)，介绍如何实现secure boot，Arm Trusted Firmware也实现了TBBR，不过每个公司实现的可能有些不一样。
CPU上电和reset都是在Secure state。例如启动时先引导Trusted OS，完成初始化后，在切换到Monitor，启动REE程序。应该不会存在暂停TEE状态的情况
理想状态下，指纹作为敏感外设是由TEE控制的，但是受到SOC和软件的一些限制，例如GPIO的设计和Trusted OS是否能够处理终端等，一般是把指纹的初始化和中断是由REE完成的，但是指纹的读取，比对，提取特征值，存储等是由TEE完成的，指纹模板存储就是用到Secure storage，不同的Secure OS之间设计可能有差异
进行world切换都是在monitor下完成的，例如ARMv8-A是在EL3（ATF），ARMv7-A是在monitor mode，在world切换时会保存当前context，恢复要切换到world的context，基本都是在存储在Secure memory. 第二个问题不存在这样的场景，建议看下ARM PSCI，ATF，OP-TEE
optee_os/utee_syscalls_asm.S at master · OP-TEE/optee_os · GitHub
硬件是没有这种限制的，要看你选用的Trusted OS或者自研的Trusted OS是如何去设计，例如这个operation设计成block的还是non-block的。例如在ARMv7时如果这个操作设计成block，一般是屏蔽中断来实现的，只有这个操作完成才返回到REE。
Int32x2 比int32x4更快，是有可能发生的，在armv7平台的话有可能是寄存器不足引起的，在armv8平台的话，有可能是指令流水排布不好引起的。你需要查看反汇编来确定具体原因，从而修改intrisics指令用法。
可能是gdb的版本的问题。我这边用GNU gdb 7.11.1在Ubuntu 16.04的AArch64 Linux下可以看到Neon寄存器的。
1：在AArch64下，使用LDP访问normal non-cacheable memory，如果地址是对齐的，AXI的transaction attribute和一条LDP指令传输的size是match的。例如：如果使用 ldp x0, x1, [x10]，会看到一个single 128bit的read。如果使用ldp q0, q1, [x10], 会看到INCR2 128bit的一个read。（AArch64应该很难发INCR4的burst）。
因为浏览器本身比较大，不太好确定是哪儿的问题。如果你怀疑是浮点相关的问题，可以先写一些相关的测试用例去测试浮点相关的计算是否有问题。再进一步分析。如果不是浮点运算的问题，那就是QtWebEngine的代码的问题了。我建议可以把出错的问题代码抽取成比较小的测试用例，把问题范围缩小再分析。
一般不会这样做。假设SoC是4*A7，每个CPU都支持TrustZone，每个CPU可以是不同的安全状态，例如CPU0是在安全状态，CPU1,2,3是在非安全状态。建议看下[链接] 会帮助你更好的理解TrustZone
