指令总线是什么

希望楼主能多分享下优化心得哈 ######心得？就是怀疑一切。我相信在Soc公司里，开发driver，特别是网络，电源管理，总线方面的朋友都知道。spec有时只能当草纸用。 ######反汇编下代码,看看编译结果有无问题.######去掉编译优化选项再试试######会不会跟子函数传递形参有关?###### 你用的是什么编译器? gcc for arm?你这个问题很可能是编译器的问题. gcc不可靠的对容易有歧义和很复杂的表达式,编译出来的东西是错误的.以前遇到过. VC的或者商用编译器就好多了. ######这么说，反汇编已经检查过了吧，如果确定汇编也没有问题的话，那就只能是硬件层的了。 编译器一般情况下是不会犯错的，因为它无论怎么优化，第一个原则就是正确性，在原程序中会被执行的代码在结果里也一定会被执行。然而，对于不同的芯片，实现上可能会有一定的差异，对编译器也有不同程度的裁剪，但它毕竟只是个程序。再者，芯片实现越来越复杂，内部指令到底是个怎么执行流程，连代码自己都不能知道，何况是编译器和程序员。###### 引用来自“ZeroOne”的答案 你用的是什么编译器? gcc for arm?你这个问题很可能是编译器的问题. gcc不可靠的对容易有歧义和很复杂的表达式,编译出来的东西是错误的.以前遇到过. VC的或者商用编译器就好多了. 上ARM 1GHz的Soc跑的准“固件”。我没办法用VC。而且是android 的NDK。 ###### 引用来自“晓寒”的答案 这么说，反汇编已经检查过了吧，如果确定汇编也没有问题的话，那就只能是硬件层的了。 编译器一般情况下是不会犯错的，因为它无论怎么优化，第一个原则就是正确性，在原程序中会被执行的代码在结果里也一定会被执行。然而，对于不同的芯片，实现上可能会有一定的差异，对编译器也有不同程度的裁剪，但它毕竟只是个程序。再者，芯片实现越来越复杂，内部指令到底是个怎么执行流程，连代码自己都不能知道，何况是编译器和程序员。 目前怀疑是函数过早跳出，对应寄存器的值没有有效传递给外部变量前，被堆栈弹出的数据覆盖，转而将数据写出变量时导致错误。虽然问题解决了。但是具体原因我还需要查一下。当然可能有另外个错误，就是进入计算和判断的变量，在寄存器传递为有些写入前，就被使用。 ######这个问题目前查清楚了，让小朋友看反汇编，让他自己理解。还不错。把问题向我汇报清楚了 。也希望大家注意， android下的C编译器存在错误。尽量把C代码写简单点。上述错误是C编译器在优化模式下的逻辑错误。

拿下代码，放入eclipse，{@fix：由于个人jdk配置，仅在jre1.6下运行}，什么输出都没有。下面来说说原因：1、对于非volatile修饰的变量，尽管jvm的优化，会导致变量的可见性问题，但这种可见性的问题也只是在短时间内高并发的情况下发生，CPU执行时会很快刷新Cache，一般的情况下很难出现，而且出现这种问题是不可预测的，与jvm, 机器配置环境等都有关。所以在未修改flag1之前，i会一直自增。一旦flag1修改后，sleep了1s,在flag2为修改之前，while循环就退出了，所以基本不会看到输出。2、说说volatile的语义。volatile能保证可见性。其保证每次对volatile变量的读取会重新从主存中获取，以使得最新修改的值对其可见。(其大概的实现方式：每次写volatile变量时，会锁定系统总线，这样会导致其他CPU的Cache失效，这样下次读取时，CPU检测到Cache失效，会重新从主存中加载)。在jdk1.5之前，volatile只能保证可见性，但会re-order的问题，这也是著名的double-check-lock的问题(对此，可google出一大堆的文章)。在jdk1.5中，对volatile语义进行了增强，其保证jvm内存模型不会对volatile修饰的变量进行重排序(写volatile变量操作不会与其之前的读写操作重排，读volatile操作不会与其后的读写操作重排)[1], 之后double-check-lock才算实际的可用。3、volatile提供的可见性和禁止指令重排的语义可以满足一定程度的同步性需求。对于volatile变量的使用，文献[2]中给出最佳实践：1.写入变量时并不依赖变量的当前值，或者可以确保只有单一线程修改该变量值；2.变量不需要和其他成员变量一起参与类的状态不变性约束；3.访问变量时，没有其他额外的原因需要加锁。

MQTT协议 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）最早是IBM开发的一个即时通讯协议，MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台，它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性：1、使用发布/订阅消息模式，提供一对多的消息发布和应用程序之间的解耦；2、消息传输不需要知道负载内容；3、使用 TCP/IP 提供网络连接；4、有三种消息发布的服务质量：QoS 0：“最多一次”，消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久后还会有第二次发送。QoS 1：“至少一次”，确保消息可以到达，但消息可能会重复。QoS 2：“只有一次”，确保消息只到达一次。例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致不正确的收费。5、小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制；在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、 可变头（Variable header）、 消息体（payload）三部分构成。MQTT的传输格式非常精小，最小的数据包只有2个bit，且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布／订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的，所以只有少量的内存空间和有限的计算能力，传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此，IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN（面向低功耗无线局域网的IPv6）的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。ACK——应答消息，接受到CON消息的响应。RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式，最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子： 比如某个设备需要从服务器端查询当前温度信息。 请求消息（CON）： GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK)： 2.05 Content “22.5 C” ，响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议，但两者还是有很大区别的，比如MQTT协议是基于TCP，而CoAP协议是基于UDP。从应用方向来分析，主要区别有以下几点： 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息，也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反，因为CoAP内置发现支持和内容协商，这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接，这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话，那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol，超文本传输协议，这个协议的提出就是为了提供和接收HTML界面，通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程，Request和Response，两个都有各自的语言格式，我们看下是什么。请求报文格式：(注意这里有个换行) 响应报文格式：(注意这里有个换行) 方法method：       这个很重要，比如说GET和POST方法，这两个是很常用的，GET就是获取什么内容，而POST就是向服务器发送什么数据。当然还有其他的，比如HTTP 1.1中还有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法（HTTP Method历史：HTTP 0.9 只有GET方法；HTTP 1.0 有GET、POST、HEAD三个方法）。请求URL:       这里填写的URL是不包含IP地址或者域名的，是主机本地文件对应的目录地址，所以我们一般看到的就是“/”。版本version：       格式是HTTP/.这样的格式，比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本，现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字，代表的是请求过程中所发生的情况，比如说200代表的是成功，404代表的是找不到文件。原因短语reason-phrase：       是状态码的可读版本，状态码就是一个数字，如果你事先不知道这个数字什么意思，可以先查看一下原因短语。首部header：       注意这里的header我们不是叫做头，而是叫做首部。可能有零个首部也可能有多个首部，每个首部包含一个名字后面跟着一个冒号，然后是一个可选的空格，接着是一个值，然后换行。实体的主体部分entity-body：       实体的主体部分包含一个任意数据组成的数据块，并不是所有的报文都包含实体的主体部分，有时候只是一个空行加换行就结束了。 下面我们举个简单的例子： 请求报文：GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文：HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议，基于REST（表述性状态传递）架构风格，支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式，最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多，太重，不够灵活。 XMPP协议 XMPP（可扩展通讯和表示协议）是一种基于可扩展标记语言（XML）的协议， 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础，而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器，然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML（标准通用标记语言的子集）流是什么样子的？客户端：123456<?xmlversion='1.0'?>to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器：1234567<?xmlversion='1.0'?>from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东西， 中间通信过程就是客户端发送XML Stanza，一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑，发送XML Stanza给客户端。但是这个过程并不是一问一答的，任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流，关闭TCP/IP连接。  网络通信过程中数据冗余率非常高，网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说，大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备，省电、省流量是所有底层服务的一个关键技术指标，XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范，是一种轻量的、简单的、 基于可扩展标记语言（XML）的协议，它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP）， 简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到 远程过程调用（RPC）等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结： 从当前物联网应用发展趋势来分析，MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商，比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早，所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展，后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者：HFK_Frank 来源：CSDN 原文：https://blog.csdn.net/acongge2010/article/details/79142380 版权声明：本文为博主原创文章，转载请附上博文链接！