最新 | 最热门 | 最高评价

+0  Unix考古记:一个“遗失”的shell

Tag: C/C++语言 | Unix/Linux | 操作系统 | 轶事趣闻 | Compiler | Interpreter | Ken Thompson | Shell | Unix
Leo 发于 2013年04月26日 22:29 | 点击: 3114 | 展开摘要
(感谢网友Leo投递此文)

谨以此文纪念伟大的计算机科学巨匠Ken Thompson和Dennis Ritchie,并同时向其他所有为Unix发展做出贡献的黑客致敬。

历史的尘埃

Unix作为一个举世闻名的操作系统已有40余年的历史,围绕着这个古老的操作系统的发展又衍生出了一系列外围软件生态群,其中一个非常重要的组件就是shell。它是操作系统最外层的接口,负责直接面向用户交互并提供内核服务,包括命令行接口(CLI)或图形界面接口(GUI)两种形式。以CLI为例,它提供

查看全文: http://www.udpwork.com/item/9728.html

+0  Compiler@NodeJS(三)- 自定义命令

Tag: 前端工具 | compiler | nodejs | 编译脚本 | 自定义命令
iAzrael 发于 2013年03月20日 23:11 | 点击: 2507 | 展开摘要
接上篇:Compiler@NodeJS(二)- 强大的管道

本来早就应该写这篇文章的,只是忙的时候忙,闲的时候懒,导致拖了这么久。

不管内置多少命令,需求总是千变万化的,这时候内置命令就不够用了,需要使用者自己编写一些命令。现在来看看怎么做。

一、内置命令

先来看看内置命令的文件结构是怎样的:

+--- compiler
+--- cmds
+--- copy
+--- concat
--- index

查看全文: http://www.udpwork.com/item/9591.html

+0  Compiler@NodeJS(二)- 强大的管道

Tag: 前端工具 | compiler | nodej | 管道 | 编译脚本
iAzrael 发于 2012年12月20日 18:01 | 点击: 1462 | 展开摘要
接上篇:Compiler@NodeJS(一) – Web项目编译脚本

直接切入主题吧。

PS:打个广告先,Compiler@NodeJS,Web开发、居家旅行、杀人越货之必备良药!

比较深入的用过linux的童鞋,一定记得这个“|”。它的使用方式是这样子的:cmd_a | cmd_b,意思是执行cmd_a 并且把cmd_a输出的结果,作为cmd_b的输入参数,传给cmd_b并执行它。例如我在shell中执行 top | grep node,就可以把进程名字包含node的

查看全文: http://www.udpwork.com/item/9596.html

+0  Compiler@NodeJS(一) – Web项目编译脚本

Tag: 前端工具 | compiler | nodejs | 编译脚本
iAzrael 发于 2012年12月20日 17:17 | 点击: 1650 | 展开摘要
转眼这一年又要到尾声了。想想这一年,貌似没干啥大事,却写了一堆杂七杂八的脚本,零零碎碎的。单个单个地用的时候是挺爽的,一旦跟已有项目结合起来的时候,由于之前的编译脚本是用python写的,没有灵活的插件机制,操作起来相当的不方便。就比如之前写的自动合图脚本(iSpriter),如果要在项目中加入,就得手动执行一次合图脚本,然后再执行python编译脚本。万一忘了合图,就会酿成发布事故。

因此,一直都在计划着用NodeJS实现一个编译脚本,可以方便的把以前写的一些脚本组合起来

查看全文: http://www.udpwork.com/item/9597.html

+0  GCC 用 C++ 来编译

Tag: 杂项资源 | 编程工具 | bootstrapping | C++ | Compiler | GNU
陈皓 发于 2012年08月20日 08:40 | 点击: 2343 | 展开摘要
GCC在2012年8月15日的时候,merge了一个patch - Merge from cxx-conversion branch,这意味着,以后在GCC的编译只能用C++的编译器了,也意味着,gcc的实现代码开始转向C++了。

你可能会有两个问题,

一个问题是为什么GCC要转成C++的实现?

没有C++的编译器,我怎么编译C++编译器的代码?这不是“鸡生蛋还是蛋生鸡”的问题么?

那,我们来看一看吧。

为什么要用C++

在GNU的C++ Conversion文档

查看全文: http://www.udpwork.com/item/7977.html

+1  代码执行的效率

Tag: 杂项资源 | 编程语言 | C++ | Coding | Compiler | Performance | PHP | Python
陈皓 发于 2012年07月13日 08:18 | 点击: 2407 | 展开摘要
在《性能调优攻略》里,我说过,要调优性需要找到程序中的Hotspot,也就是被调用最多的地方,这种地方,只要你能优化一点点,你的性能就会有质的提高。在这里我给大家举三个关于代码执行效率的例子(它们都来自于网上)

第一个例子

PHP中Getter和Setter的效率(来源reddit)

这个例子比较简单,你可以跳过。

考虑下面的PHP代码:我们可看到,使用Getter/Setter的方式,性能要比直接读写成员变量要差一倍以上。

<?php
//dog_nai

查看全文: http://www.udpwork.com/item/7697.html

-1  编译内存屏障(Compiler Memory Barrier)第二讲

Tag: JVM | Compiler Memory Barrier | GCC | JMM
fp1203 发于 2012年01月11日 11:39 | 点击: 4062 | 展开摘要
上一篇 编译内存屏障(Compiler Memory Barrier)第一讲

1. gcc编译的大致过程

可以看到,gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化;

前文所说的指令调度(Instruction scheduling)即为RTL优化的一部分。

2. 从RTL指令调度出发,追寻Compiler Memory Barrier的踪迹

还是从实验出发,实验代码如下:

volatile int rea

查看全文: http://www.udpwork.com/item/6679.html

+1  编译内存屏障(Compiler Memory Barrier)第一讲

Tag: JVM | Compiler Memory Barrier | GCC | RTL | volatile
fp1203 发于 2012年01月11日 11:11 | 点击: 7376 | 展开摘要
1. 编译优化导致编译器指令重排

要想理解Compiler Memory Barrier,先要理解Compiler Instruction Reorder,即编译器指令重排。

编译器指令重排是编译优化的结果,以gcc来说,它不知道为我们的代码默默做了多少事情,看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验,来逐步分析Compiler Memory Barrier的作用。

gcc的很多优化都可以造成指令重排,最常见的就是基本块重新排序(B

查看全文: http://www.udpwork.com/item/6680.html
|<<<1>>>| 一共1页, 8条记录