新名字 duangsuse /'dʊɔːŋ sjuːz/ | [⃪PROM, FP]

显得简单一些

| [⃪PLD, FPλ]

这样 PLD 和 FP 就不会被误读了（PLD 是，好像是 FPGA 更好，其实是说 duangsuse 感兴趣的低到嵌入式层面，可是如果熟悉电子设计一定会知道 Programmable Logic Device 的）
FP 后面加上 lambda 符号肯定是说函数式编程的 FP 呢

不得不说，这是大小端的问题非常喜感，我明明什么都没做，只是保存了一下文件... 就自动帮我反色了

不，其实是我写错了... 好像多输出了一个字节，我都不知道从哪里来的，可是它影响了 BMP 矩阵的解释（shift 了一个位置，结果会导致这样的颜色值问题）...

前面的元数据一毛一样，可是后面的矩阵却被多写了一个字节

我只好注释掉了这个... 我觉得比较有用的流位置指定

初步考证可能是由于 reader 程序对动态大小结构 DIB 的处理有问题，正在修复

表现的现象是读取矩阵时往前 seek 一个字节就不会出问题（不会影响颜色值的解释），但这么做输出的文件依然和源文件不同

我也在怀疑是不是索引格式的问题（零基和非零基什么的）

果不其然... DIP Header 把长度自己本身 4 字节的大小也算在里面了...

使用 GIMP 以预期的 ARGB 方式导出，解决了 8-bit 色值长度不对称导致计算错误 segment fault 的问题，现在可以进行 DIP

如此邪恶的图片果然就应该是非常邪恶的 SIMD 程序弄出来的... 当然，直接使用循环向量化都可以，说到这个我就想到蛤为，其实本来靠 call-tree 分析都可以做的优化算什么呢？其实比这些难的 LLVM Cookbook 这种快速入门上都有教...

可以说是非常邪恶的 DIP 算法了...

个人感觉：还有点意思，待会发 GitHub 并且附上测试手册

其实后来算算 CPU time （就是处理器内部的时钟，一般和晶震同步）发现也没有什么特别的高性能，但这个实际上是每次能处理 4* long long （两个像素），也就是说一次能算出八个像素的，如果加上多线程可以试试，但需要注意的是这个并非传统的反色（而是 bitwise and），传统反色可以用 0xff- 或者 xor 去算，我再写一个...

MASK=ff0000ff FASTINV= ./build/bitmaprevcolorsimd avatar.bmp out.bmp

哇，这张好看

看起来像是莫名其妙，我也不知道是为什么，但是后来就是这个样子... 显得很沧桑的感觉；好像是某种函数图像啊

"Why functional programming matters?" 因为模块化是成功的关键，虽然 C 写起来很有感觉，但是模块化真的是个辣鸡

#C 突然想到 C99 还是 C11 开始还有 _align marker...

这次的 X86 简易 SIMD 体验因为时间安排原因不得不告一段落了，处理时主要使用了 MMX 的简单大长度并行处理，没有使用平时信号处理领域 DSP 芯片等需要使用的 Multiply & Add 算法什么的；一共 2k 多行代码，大部分是 C

最后果然还是引入了新问题，就是我不知道为什么它会变成这样... 看起来不是线程同步的问题，因为它同样参数可以多次输出同样的位图... #cg #hp 看来现在是没法解决了，这个问题留给以后吧；或许改日我用内联汇编的方式再写一个更好用的

https://www.ibm.com/developerworks/cn/linux/l-gccsimd/ #recommended #hp

开源在 GitHub:Essay-DIP-BMP-SIMD-Operation

正在准备完成剩下的东西...

这周事情挺多的，看来又是做不完 👉

Essay-Fibonacci-Generator
Essay-Cached-Factorial-Stream
Essay-Java-Annotations
(Runtime, Processor, Andriod)
JavaPrefer (Preference DSL)
Essay-Android-Lime-Tokenize
(Fragments & Item model)
Java BinaryStreamIO
Essay-Compilers-LLVM-Toy
Essay-PL-Java-Miniλ
GC For the Radium Programming Language