MD5 (Message Digest Algorithm 5) は、 RFC 1321 でアルゴリズムが紹介されていて、 Appendix (付録) として C によるリファレンス実装が付属しているが、 その global.h に /* UINT4 defines a four byte word */ typedef unsigned long int UINT4; と書いてある。 すなわち 32bit 整数として UINT4 型を定義している。 x86_64 Linux を始め多くの 64bit Unix は LP64 すなわち long int (とポインタ) が 64bit な整数データモデルを採用している。 したがって UINT4 型の定義が 「unsigned long int」 のままで、 この MD5 リファレンス実装を使ってしまうと、 32bit であるべき UINT4
はなおか じった 世界遺産の近くに住んでます。 Microsoft MVP for Visual Developer ASP/ASP.NET 10, 2004 - 9, 2011 x64 環境なのかどうかの判定をする方法。 OS のバージョンを見ても、x64 なのかどうかはわかりません。例えば、32ビット版 Windows XP のバージョンは 5.1 ですが、64ビット版の場合は 5.2 になります。しかし、Windows Server 2003 も、5.2 です。なので、別の方法で調べます。 MSDN を調べると、IsWow64Process 関数（英語）が見つかります。しかし、「64ビット OS 上で動く64ビット アプリケーションの場合は、この関数は FALSE を返す」のだそうです。一応、それなりに作り込めば、32ビット アプリケーションと64ビット アプリケーションは、同じコー
Intel 64 and IA-32 Architectures Software Developer's Manual を読んでも ModR/M や SIB が理解できない。 x86系CPUのネイティブコードを解析する（2/3）：CodeZine を読んでやっと理解できた。日本語でまとまっているのは大変ありがたい。 例えば以下のアセンブリをアセンブルする。 (movq (& rbx #x30) rcx) まず上に挙げた Intel のリファレンスで MOV を調べる。するといくつかのタイプが列挙されているのが分かる。 今回のケースは「 Move r64 to r/m64 」に該当するので以下の行が見つかるはず。 REX.W + 89/r MOV r/m64, r64 ここで分かる事は #x48 (REX.W) が必要 MOV の opcode は #x89 であること。 次に ModR/
We created a patch to build FastCGI client library for 64bit windows. This patch is based on fcgi-2.4.0.tar.gz available on FastCGI official site. Download fcgi-2.4.0-x64.patch See README.win64 file after extracting the archive and applying the patch Changelog and how to build are described in the file.
Windows@i386でのatomic 64bit store。_InterlockedCompareExchange64を使ったほうがいいのかな？だいたい、ちゃんと動作してるのかしら…ツッコミ求む。 #include <windows.h> #include <stdio.h> #define int32_t INT32 #define uint32_t UINT32 #define int64_t INT64 #define uint64_t UINT64 void atomic_set_64bit(uint64_t *p, uint64_t v) { uint32_t v1, v2; v1 = *(((uint32_t *)&(v))+0); v2 = *(((uint32_t *)&(v))+1); __asm { _set_loop: mov esi, p mov ebx, v
本日オライリージャパン様より「Debug Hacks――デバッグを極めるテクニック＆ツール」の献本をいただきました。著者の皆様、出版社の皆様ありがとうございます。 とりあえず、ざっくりと気になる章だけをかいつまんで読んでみたのですが、最後の章「#66.手元のx86マシンが64bitモード対応かどうかを調べる」では、/proc/cpuinfo で lm の文字列を探す方法と、以下のような CPUID 命令を発行して今自分が使っているマシンのCPUが64bitに対応しているかどうかを調べるハックが紹介されていました。 #include <stdio.h> void cpuid(int op, unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx) { __asm__("cpuid" : "=a" (
Products Processors Accelerators Graphics Adaptive SoCs, FPGAs, & SOMs Software, Tools, & Apps
Yasm extends the base NASM syntax to support AMD64 as follows. To enable assembly of instructions for the 64-bit mode of AMD64 processors, use the directive BITS 64. As with NASM's BITS directive, this does not change the format of the output object file to 64 bits; it only changes the assembler mode to assume that the instructions being assembled will be run in 64-bit mode. To specify an AMD64 ob
ふと思い立って YARV からの JIT コンパイラを Xbyak で書き始めてみました。 x86 と x86_64 を両方サポートするつもりだったけど、とりあえず適当にやりすぎて x86_64 に依存しまくってしまったのでとりあえず現状そっちだけ。今度 x86 対応はちゃんとやる。あと Windows と MacOSX もたぶんまだだめ(調べられる環境すらない)。 http://shinh.skr.jp/tmp/yajit.tgz YA なのはなんか他にやってた人いるみたいだし、私の記憶が確かなら YARV にも昔そういう最適化フラグあったような。実装されてたかは知らんけど。 とりあえず動くコードもあれば動かんコードも…って感じです。速いかというと…遅い気がする。とりあえずブロック呼び出しごとに mprotect してるとかがあまりに問題外すぎる気がする。とりあえずこんなとても恣意的なベ
最近，Visual C++ のことを高機能なマクロアセンブラだと思っている光成です． その考えを64bit Windows/Linuxにも押し進めるため，64bitに対応したJITアセンブラXbyakを公開しました． 64bit Visual Studioではインラインアセンブラが廃止されたため，何かと便利になるのではないかと思います． ところでWikipediaのAMD64などには64bit Windowsに関して 64ビットアプリケーションではx87命令・MMX命令及び3DNow!命令をサポートしない（x87レジスタをコンテキストスイッチの際にセーブしない） という記述があるのですが，試したところちゃんとセーブされているようです． テスト方法 test_mmx.cppをコンパイルして(binary) コマンドプロンプトを二つ開いて test_mmx 1 test_mmx 3 と実行しま
gccでatomicに64bitの値を代入したい。 一応、以下のようなコードで実現はできるんだけど。。 #include <stdio.h> #include <stdint.h> #define SEN_SET_64BIT(p,v) \ __asm__ __volatile__ ("1:\n" \ "\tmovl (%0), %%eax\n" \ "\tmovl 4(%0), %%edx\n" \ "\tlock; cmpxchg8b (%0)\n" \ "\tjnz 1b\n" \ : \ : "D"(p), "b"(*(((uint32_t *)&(v))+0)), "c"(*(((uint32_t *)&(v))+1)) \ : "ax", "dx", "memory"); int main (int argc, char *argv[]) { uint64_t a = 0x012
次のようなプログラム test.c について考える: #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <string.h> struct test { int32_t len; int8_t buf[16]; }; int main(int argc, char *argv[]) { struct test *p = malloc(sizeof(struct test)); int8_t buf[16]; p->len = sizeof(p->buf); bzero(p->buf, p->len); printf("0x%lX-0x%lX => 0x%lX\n", (long)p->buf, (long)p->buf+p->len-1, (long)buf); bcopy(p->buf, buf,
最近メモリが安いので，Dell PowerEdge SC420 にメモリ 4GB とおごってみました。ところが OS から見えるメモリは 3GB 強程度。さらっと調べた感じだと， PAE を有効にすればできるよ，たぶん x86_64 な OS だと大丈夫だよ，たぶん という意見がよく出てくるのですが，私の環境では PAE カーネルにしてもだめでした。ということであれこれ探し回って，4GB（以上）のメモリを使うために何が必要なのかを調べてみました。 結論ですが， ハードウェアサイドの要件として IA32 の場合 CPU が PAE（物理アドレス拡張）に対応していること といっても 4GB もメモリを詰めるような環境では当然対応してます チップセットが 8GB 以上のメモリをサポートしていること MCH（昔でいう North Bridge）が 33 bit 以上のアドレス空間を利用できる必要が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く