为什么随着PIC强大控制会少？

有些人喜欢ASM。有些人需要ASM.ASM，在大型项目上总是很难适应。它永远不会消失。



      以下为原文

    Some people like ASM.
Some people need ASM.
ASM was always harder to scale for big projects.
 
It can never disappear.

对于许多项目，时间关键位少于总代码的10%。我现在用C语言做最多，在需要时只用汇编语言中的小部分。



      以下为原文

    For many projects, the time critical bits are less than 10% of the total code.
I now do most in C, with just small sections in assembler where needed.
 
 

程序集有生存的权利，但也不存在软件的“正常”部分。在最大速度的地方，或者对于非常特殊的算法，我诉诸于汇编。但是我的大部分代码是——虽然非常资源意识——在C/C++中。



      以下为原文

    Assembly has its right to exist - but nor for the 'normal' parts of software.
 
Where maximum speed counts, or for very special algorithms, I resort to assembly.
But the majority of my code is - though very resource-aware - in C/C++.

我也喜欢汇编程序。一直使用它。



      以下为原文

    I like assembler too. Use it all the time.
 

我在C（C18）中做我所有的时间关键的事情，下降到+/-1的生成比特流的精度。一旦你理解编译器做了什么，就不难了。低位位旋转代码编译几乎1:1汇编。在XC8中，我不会尝试同样的代码：



      以下为原文

    I do all my time critical stuff in C (C18), down to +/-1 us accuracy of generated bit streams. Once you understand what the compiler does it is not difficult. Low level bit twiddling code compiles almost 1:1 to assembly.
 
I wouldn't attempt the same in XC8 :(

我只使用组件100%。除了巨大的速度优势，代码大小差异通常意味着使用程序内存较小的部分，从而降低成本。我一直在为公司做合同工作，将基于Atoml的项目转换为PIC，将C转换为组装，降低成本，提高性能。



      以下为原文

    I use assembly 100% exclusively.  Besides the huge speed benefit, the code size difference most often means using a part with smaller program memory, thus reducing costs.  I am constantly doing contract work for companies converting Atmel based projects over to PIC and converting C to assembly, reducing their cost and improving performance.
 
 

ASM为PIC16，C为PIC24，不确定PIC18XC8有几个“什么”时刻。



      以下为原文

    ASM for PIC16 , and C for PIC24  , not sure about PIC18 XC8 has a few "what" moments. 

我用汇编5.3。



      以下为原文

    I use assembly 5.3.

热衷于编写一个TCP/IP协议栈有很多Server汇编？



      以下为原文

    keen to write a tcp/ip stack with lots of sercices in assembly? 

HTTP://www. TiBu.COM/TIOBE-索引/ /在前十！



      以下为原文

    http://www.tiobe.com/tiobe-index//
 
In the top ten!

汇编哲学是相反的。用汇编语言编写代码时，可以避免膨胀（例如“许多服务”），而只编写所需的内容。



      以下为原文

   


Assembler philosophy is opposite. When you write in assembler, you avoid bloat (such as "lots of services", which may get handy some day) and write only what you need.

我不确定TCP/IP，但是人们已经在汇编中编写了USB，即使是PIC12F675！



      以下为原文

   
I'm not sure about TCP/IP but people have written USB in assembly, even for a PIC12F675!

死在32位CPU的大多数代码。这些通常都是大规模的项目。除了时间关键代码之外，大多数都在16位CPU中死亡。编译器非常好，非常活跃，而且8位运行良好，这主要是由于“免费”C编译器的代码生成很差。OES需要更多的时间来编码ASM比C）…



      以下为原文

    dead in 32 bit cpu for most code.  These are generally large scale projects anyway.
mostly dead in 16 bit cpu except for time critical code.  The compiler is pretty darn good.
alive and kicking in 8 bit, mostly due to the poor code generation of the "free" C compilers.
 
It really depends upon the size of the dev team, the scale and scope of the project, who is going to maintain the code, time to market (you can think whatever you want, it does take more time to code asm than C) ...

汇编哲学是相反的。在汇编语言中编写时，可以避免膨胀（例如“许多服务”），而只编写您需要的内容。所以在ASM中编写Harmony是不可能的？汇编程序总是会有地方的。但是请记住，早期的ASM程序员是制作第一个HLL的程序员。我们可以肯定第一个编译器是用ASM编写的。它有它的局限性。并且需要比Java或C更高的技术水平，而且它需要硬件和芯片指令集的知识。



      以下为原文

   


Assembler philosophy is opposite. When you write in assembler, you avoid bloat (such as "lots of services", which may get handy some day) and write only what you need.


So It would be impossible to write Harmony in ASM?
 
Assembler always will have a place.  But remember the early ASM programmers are the ones that made the first HLL. And we can be sure the first compiler was written in ASM.  It has its limitations.  And requires a higher skill level than Java or even C.  Plus it requires knowledge of the Hardware and chip instruction set.

当然是可能的，但是你不会有太多的收获。而且，MIPS实际上是为C编写的，除了一些特殊情况，如调试执行程序，大多数人无论如何都不会在其上使用Assembler。



      以下为原文

   


Certainly possible, but you wouldn't gain much. Also MIPS is literally cooked for C, so most people probably wouldn't use Assembler on it anyway, except for some special cases, such as debug executive.
 

我一直认为最好的路径是C，用汇编语言做小的优化的块。



      以下为原文

    I keep on thinking that the best route is C, with assembler for small, optimized chunks..

我不会这么说。XC16编译器效率相当低，所以即使为了性能提高而使用汇编程序，在大多数情况下也是合理的。如果使用汇编程序是因为您想以某种特殊的方式构造程序，那么C编译器有多好并不重要。大规模的项目，经常来自膨胀（例如，糟糕的计划，极低效率或不需要的代码等），而不是来自必要性。膨胀对于嵌入式世界来说是新的，但是在它成熟的PC世界中，它很容易是100-1或更多。因此，通过良好的规划，大型项目可能会变得更小。我并不是说这些项目必须用汇编语言编写。然而，仅仅因为项目必须臃肿而避免汇编程序对我来说似乎不太合乎逻辑。



      以下为原文

   


I wouldn't say that. The XC16 compiler is rather very inefficient, so even if you would use assembler just for performance gain, it would be justified in most cases.
 
If you use assembler because you want to structure your program in some special way, then it doesn't really matter how good the C compiler is.
 
Concerning the large-scale projects, the scale often comes from bloat (e.g. bad planning, extremely inefficient or unneeded code etc.) rather than from the necessity. Bloat is new to embedded world, but in the PC world where it is maturing it could easily be 100:1 or more. So, with good planning, large-scale projects may get much smaller. I'm not saying that such projects must be written in Assembler. However, avoiding Assembler just because the project has to be bloated doesn't seem very logical to me.
 

当然是可能的，但是你不会有太多的收获。而且，MIPS实际上是为C编写的，除了一些特殊情况（如调试执行器）之外，大多数人都不会在C上使用Assembler。对不起，这是关于Harmony的讽刺性讽刺。避免膨胀（如“许多服务”），这可能有一天会变得方便。Harmony恰恰相反。任何东西都可以用ASM编码。



      以下为原文

   


Certainly possible, but you wouldn't gain much. Also MIPS is literally cooked for C, so most people probably wouldn't use Assembler on it anyway, except for some special cases, such as debug executive.




Sorry it was a sarcastic quip about Harmony.
"avoid bloat (such as "lots of services", which may get handy some day"
Harmony is the exact opposite.
 
I realize anything can be Coded in ASM.

我也是恐龙，我想，从ASM的几十年开始，6502, 68000年，用PIC18ASM启动，在ASM中变成PIC 24/30／33。对于我来说，ASM中容易编写代码，不需要C.RMH。



      以下为原文

    i am a dinosaur too i think.
started with 6502, 68000 in asm decades ago.
started many years ago with pic18 asm, and changed to pic 24/30/33 in asm.
for me its easy to write code in asm, no need for C.
rmh