terraspace / uasm Goto Github PK
View Code? Open in Web Editor NEWUASM - Macro Assembler
Home Page: http://www.terraspace.co.uk/uasm.html
License: Other
UASM - Macro Assembler
Home Page: http://www.terraspace.co.uk/uasm.html
License: Other
0000000000402004 C5 FC 77 vzeroall
0000000000402007 C5 F8 77 vzeroupper
This is what the encoding should be.. so this is a BUG.
HJWASM is encoding vzeroall as vzeroupper
Example:
include \masm32\include\masm32rt.inc
opax macro arg
Local oa, tmp$
oa = opattr arg
tmp$ CATSTR <TheArg=>, , < with opattr=>, %oa
% echo tmp$
ENDM
.code
start:
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx] ; <<<< assembles fine with MASM
print "ok"
exit
end start
movq mm0,[eax]; 0F 6F 00 ; ok
movq [eax],mm0; 0F 7E 00 ; wrong (it's movd, not movq), should be 0F 7F 00
movd mm0,[eax]; 0F 6E 00 ; ok
movd [eax],mm0; 0F 7E 00 ; ok
movd xmm0,[eax]; 66 0F 6E 00; ok
movd [eax],xmm0; 66 0F 7E 00; ok
movq xmm0,[eax]; F3 0F 7E 00; ok
movq [eax],mm0; 66 0F D6 00; ok
invalid instruction operands when using dr0 - dr7
Running hjwasm 2.28 on a 64-bit linux system (32-bit Windows version still crashes rather than displaying error messages), I get a rather unhelpful error message:
Error A2168: General Failure
Command line:
./hjwasm -archAVX -DX86_64 -DWINDOWS64 -DARCH=FMA3 yr4dwpn.asm
Source code:
https://www.dropbox.com/s/b5mptuq6hxs3es6/hjbug.tgz?dl=0
The Windows 32-bit debug version you built for me was not helpful in tracking down the Windows crash bug. MSVC 2005 won't attach to the crashed executable. I do not have a newer MSVC version.
If I assemble mult.asm with these command line arguments (/c -Fl -Sf -Sa -Sg -coff), I get no errors. See file mult.no_errors.lst.
If I assemble mult.asm with these command line arguments (/c -Fl -coff), I get 3 errors. See mult.errors.lst.
mov ecx, [esp+4] ; Address of data struct to return info
Error A2014: invalid combination of opcode and operands
mov eax, OFFSET xjmptable ; SSE2 mersenne mod FFTs
Error A2014: invalid combination of opcode and operands
ret
Error A2014: invalid combination of opcode and operands
As always, MASM has no problems. The next source file to assemble (mult1.asm) has even more problems. Here is a link to the entire MASM code base: https://www.dropbox.com/s/rpkstsv1m1kj4bc/gwnum.zip?dl=0
C.bat starts the assembly process using a makefile called "compile". C64.bat does the same thing for 64-bit assembly. Enjoy, it will be a good test case!
;Strangely, forward JMP is correct but backward is not.
.386
.MODEL FLAT
.CODE
Proc1 PROC NEAR
test eax,eax; 85 C0
JNZ @@over ; 75 06 -ok
test eax,eax; 85 C0
JNZ @@ret ; 75 00 -ok
@@ret:
CLC ; F8
RET ; C3
@@over:
test eax,eax ; 85 C0
JNZ @@ret; 75 FA -ok
test eax,eax ; 85 C0
JNZ @@ret; 75 F6 -ok
Proc1 ENDP
TestEpilogue MACRO procname, flag, parmbytes, localbytes, reglist, userparms
CLC
RET
ENDM
OPTION EPILOGUE:TestEpilogue
Proc2 PROC NEAR
test eax,eax ; 85 C0
JZ @@over; 74 06 - ok
test eax,eax ; 85 C0
JNZ @@ret; 75 00 - ok
@@ret: RET; F8 C3; epilogue ok
@@over:
test eax,eax ; 85 C0
JNZ @@ret ; 75 FE - wrong - makes infinite loop
test eax,eax ; 85 C0
JNZ @@ret; 75 FE - wrong
Proc2 ENDP
END
vmovdqu zmm14, ZMMWORD PTR [r14][rdx]
assembles as
vmovdqu32 (%rdx,%r14,1),%zmm14
according to gcc ... that looks right to me.
But,
vmovdqa ZMMWORD PTR [rdi][rdx], zmm14
assembles as:
vmovdqa32 %xmm14,(%rdx,%r15,1)
according to gcc.
Also, this
vpandn ymm14, ymm15, ymm14
assembles as:
(bad)
according to gcc. But it does execute properly.
In 32-bit the Borland/Delphi Register calling convention (this is the default calling convention in Delphi) passes the firsts 3 parameters in registers EAX, EDX and ECX, in this order. Remaining parameters follow the stdcall convention.
I believe this is not a complicated addition and will add significant value and differentiation to HJWASM.
Currently incbin of a 137kb file increases assembly time by about 5 seconds. This becomes exponentially worse as the file size increases.
.686
.XMM
.MODEL FLAT
.CODE
pinsrw mm0, eax, 0 ; 0F C4 C0 00; ok
pextrw eax, mm0, 0 ; Error A2049: Invalid instruction operands
; - should be 0F C5 C0 00
pextrw eax, xmm0, 0 ; 66 0F C5 C0 00; ok
pinsrw xmm0, eax, 0 ; 66 0F C4 C0 00; ok
Using Nov 20th version.
vpsraq ymm15, ymm6, 63 ; Create mask for each negative count
is reported as this by gdb disassembly:
vpsrad $0x3f,%ymm6,%ymm15
Note the "d" instead of "q"
vpsraq ymm15, ymm8, 63
is reported by gdb as "(bad)"
vpandn ymm14, ymm15, ymm14
is reported by gdb as "(bad)"
I'm using a fairly old binutils, so I've no idea where the problem lies. Program executes OK.
This code:
vpand zmm2, zmm2, zmm0
vpmovmskb rcx, zmm2
sub rdx, rdx
Produces this in objconv disassembly:
?_236:; vpandd zmm2, zmm2, zmm0 ; 4CB3 _ 62 F1 6D 48: DB. D0
db 62H, 0F1H, 6DH, 48H, 0DBH, 0D0H
; Error: This instruction is not allowed in 64 bit mode
; Error: VEX.mmmm bits out of range
; Note: Prefix bit or byte has no meaning in this context
; Note: VEX prefix bits not allowed here
; Warning: MVEX prefix not allowed for this instruction
; Warning: MVEX prefix option bits not allowed here
; dec r8d ; 4CB9 _ 62 C4 F1 FD: 48
db 62H, 0C4H, 0F1H, 0FDH, 48H
; xlatb ; 4CBE _ D7
db 0D7H
; retf 11080 ; 4CBF _ CA, 2B48
db 0CAH, 48H, 2BH
oa = opattr arg
tmp$ CATSTR <TheArg=>, , < with opattr=>, %oa
% echo tmp$
; TheArg="a string" with opattr=36 ; HJWasm64
; TheArg="a string" with opattr=36 ; ML 10.0
ENDM
.code
start:
opax "a string" ; <<<<<<<<< 0 with ML, 36 with HJWasm
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx] ; <<<< assembles fine with MASM
print "ok"
exit
end start
I am attempting to compile Agner Fog's asmlib files with jwasm for usage in 64bit Linux.
I am having problems with the 64bit ELF format regarding the relocation section names.
When I compile my gnu asm and run readelf -a on the files, I see that I have Relocation section '.rela.text' and '.rela.data', but when using jwasm, I only get '.rel.text' and '.rel.data'.
When I attempt to link the object code to my other objects, I have relocation problems on the linkage. I feel like there need to be some patches to the elf.c code?
Can anybody help me with this, or tell me how I might go about fixing it without becoming an expert on the ELF format?
I also run into a bunch of R_X86_64_PC32 relocation errors stating that I need to recompile the code with -fPIC for some of the assembly files. I haven't figured out how to get around this one either. Typically, I code in straight GNU ASM and use %RIP relative offsets for functions/labels/vars, but this seems to be a little bit different in the MASM world. - any help would be appreciated.
Link
JROC
JROC
2010-10-30
I also wanted to mention that I think this assembler is pretty awesome.
AND.. I found that when compiled as a 64bit executable, it is broken.
On RedHat 5.5 x86_64, I had to modify the gcc unix make file to have -m32 for all the cflags to build jwasm such that it would produce usable results. I'm not quite sure what in the sources didn't work under the 64bit compilation. I didn't take the time to figure it out since I'm mainly focused on getting Agner Fog's library compiled under 64bit and working correctly.
Link
japheth
japheth
2010-10-31
When I attempt to link the object code to my other objects, I have relocation problems on the linkage. I feel like there need to be some patches to the elf.c code?
I'll need at least a test case to see those "relocation problems" myself
Link
JROC
JROC
2010-11-01
Ok, I've sent a tarball to what I am guessing is your source forge email address. Please let me if you receive it.
It's a test case of attempting to build a shared object file under x86_64 linux.
Thanks,
Eric
Link
japheth
japheth
2010-11-02
I received it.
Link
JROC
JROC
2010-11-02
great… - thanks.
Link
japheth
japheth
2010-11-03
I took a look.
There are 64-bit offsets in the assembly source, which make JWasm generate R_X86_64_64 relocations in .rel.data. This isn't compatible with PIC.
Generally, JWasm still lacks ELF-specific operators ( something like IMAGEREL/SECTIONREL for coff ) to support relocations which are to go into .rel.dyn and/or rel.plt. I guess, without such operators PIC code will be difficult to write with JWasm.
The small bug concerning forward references (memcpy64.asm.fails_with_jwasm) has been fixed.
Link
JROC
JROC
2010-11-03
thanks for taking a look and getting that other bug fixed.
am I correct to assume that 64bit PIC support will be well off into the future at this point?
For what it's worth, the nasm source code has what appears to be a fairly robust elf64.c file that might support the 64 bit PIC operations. That might be a good source for comparison.
Link
japheth
japheth
2010-11-03
am I correct to assume that 64bit PIC support will be well off into the future at this point?
this topic made me think about the priorities. Support for shared object should clearly have a higher priority than support for the dwarf debugging format.
That doesn't mean it will be implemented in 2 weeks. IMO the big problem with this issue is that currently there exists no convincing implementation of shared object support in current intel-based assemblers (NASM/YASM/FASM). It's all very low-level and error-prone - who has ever used this stuff?
Link
JROC
JROC
2010-11-03
Obviously, the intricacies of the object file formats are a bit over my head at the moment, but after this latest attempt to compile and link Agner's fast memcopy/memset routines they are starting to gain my attention.
The sad thing is, I never even heard of dwarf before until I started seeing it my compiled assembly dumps. I have been stripping all of the dwarf related stuff out of my assembly code, so as far as I know (naively speaking) I have no need for dwarf info at the moment.
I'll keep watching the forum to see how the progress is going. In the meantime, I'm hand converting the memcpy64.asm over to GAS format. I hope I can figure it out. I just started doing assembly hard core a month ago.
Link
JROC
JROC
2010-11-04
I ported the memcpy64.asm over to GAS assembly as PIC code (%rip relative) and it seems to be working fine.
If you are interested in having a copy of it to use in debugging of these problems, let me know and I will email it to you.
Link
drizz
drizz
2010-11-05
+1 for this feature and for lin64-abi-"invoke"
the way i understand it, it is impossible to call external functions with -elf64?
as a workaround you can compile to "-win64" and convert with objconv (Agner Fog)
jwasm -q -c -win64 -zcw -Fo $object $file
wine objconv.exe -felf64 -wd2005 -nu $object $object
// $object $file are code::blocks macros
This line is crashing on Knight's Landing (output is from objconv):
korw k5, k1, k2 ; 79A4 _ C5 F0: 45. EA
I wrote this gcc program:
int main () {
__asm__ volatile (\
"korw %k5, %k1, %k2\n\t");
}
and it works. Under gdb, the kor instruction compiled as:
c5 f4 45 d5
Would SSH access to a Linux Knight's Landing machine be of any use?
In .386 mode
0000000F 6C0000 ins [vb],dx
00000012 6D0000 ins [vw],dx
00000015 666D0000 ins [vd],dx
00000019 6C0000 ins es:[vb],dx
These should be:
0000000F 6C ins [vb],dx
00000010 6D ins [vw],dx
00000011 666D ins [vd],dx
00000013 6C ins es:[vb],dx
Hjwasm –c –bin –Sg –Fl inout.asm
Available from VS2013 onwards,
supports passing of XMMWORD, YMMWORD, ZMMWORD types through registers like fastcall.
Create a gitter.im room and display gitter badge on readme.md - useful for discussions and it integrates with github and you can reference issues and commits directly in chat which shows as links back to repo for the issue/commit/pull request/comments
x64dbg uses one, https://github.com/x64dbg/x64dbg
Here is x64dbg's gitter page: x64dbg gitter
Users can use a gitter desktop client (windows: http://update.gitter.im/win/latest - mac/linux also available) or web or mobile (iphone/android)
vbroadcastsd zmm16, QWORD PTR ZMM_FMA_RND_CONST3
will not assemble.
Believe it or not, I do have working AVX-512 code so we are getting close to working out all the kinks that affect me.
Regarding the AMD trouble I was having, I eyeballed the code and found an AVX2 instruction in my FMA code path (Piledriver crash) and an SSE4 instruction in my SSE2 code path (K10 crash). Consequently, I believe the assembly that is not gcc compatible is not high priority. GDB users will want full compatibility for correct disassembly and ease of placing breakpoints.
[code]
vpsllq xmm0, xmm1, xmm2
[/code]
This one is a BUG, the src/dst registers are being encoded the wrong way around.
[code]
C4E2FD190500000000 vbroadcastsd ymm0, m64
[/code]
The W bit of the 3 byte vex encoding SHOULD be 0 yielding 7D not FD as the 3rd byte... bug
One example is the instruction vaddpd ymm10, ymm10, ymm11
. Output from objconv:
' vaddpd ymm10, ymm10, ymm11 ; 6ECC _ C4 41 Ad: 58. D3
; Note: Prefix bit or byte has no meaning in this context`
Output from https://defuse.ca/online-x86-assembler.htm#disassembly2
0: c4 41 ad 58 (bad)
4: d3 .byte 0xd3
Knights Landing will execute this code correctly. However, debugging is a bit hard in gdb as disassembly is not possible.
One of my users is getting crashes on Piledriver. I don't have access to an AMD cpu so I do not know if the crash is due to encodings like the above or a bug in my code.
Latest HJWAsm32 crashes. Download the zip file below. Run crash.bat. Sorry the zip file is so big, trimming it down to minimum size would be a bit tedious.
https://www.dropbox.com/s/08kf4qyssvq48yy/hjwasm_crash.zip?dl=0
Guys, you are missing the basics of git.
How can we port your changes to JWasm if 99% of your's changes is updating of compiler generated object files.
.while !(eax || edx) && ecx
nop
.endw
"" and L"" and 2.3f, 2.3 etc in invoke.
I'm converting a large project from ML64 to HJWASM 2.15 dated Sept 14. Using objconv to disassemble the resulting object files produces numerous differences:
ML64 disassembled:
?_204: vpsrlq ymm3, ymm1, 3 ; 3878 _ C5 E5: 73. D1, 03
vpand ymm0, ymm3, ymm15 ; 387D _ C4 C1 65: DB. C7
HJWASM disassembled (registers reversed, scary error message):
?_204: vpsrlq ymm1, ymm3, 3 ; 3878 _ C5 F5: 73. D3, 03
; Note: Prefix bit or byte has no meaning in this context
vpand ymm0, ymm3, ymm15 ; 387D _ C4 C1 E5: DB. C7
ML64:
vpsrlq ymm9, ymm7, 3 ; 3899 _ C5 B5: 73. D7, 03
HJWASM (wrong register & scary message):
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm15, 3 ; 3899 _ C4 C1 B5: 73. D7, 03
vpaddq, vpmuludq instructions also generate scary error message
ML64:
vpxor ymm2, ymm2, ymm2 ; 3973 _ C5 ED: EF. D2
vpcmpeqq ymm3, ymm3, ymm2 ; 3977 _ C4 E2 65: 29. DA
HJWASM:
vpxor ymm2, ymm2, ymm2 ; 3974 _ C5 ED: EF. D2
; Note: Prefix bit or byte has no meaning in this context
; Note: Unknown opcode reserved for future extensions
; Note: VEX prefix bits not allowed here
UNDEFINED UNKNOWN REGISTER TYPE 3, ; 3978 _ C4 E3 E5: 1F. DA, 00
more examples of objconv error messages where ml64 output is complaint-free:
; Note: Prefix bit or byte has no meaning in this context
vmovsd xmm0, qword ptr [r11+0B0H] ; 0000000E _ C4 C1 FB: 10. 83, 000000B0
; Note: Prefix bit or byte has no meaning in this context
vmovapd ymm14, ymmword ptr [r11+780H] ; 00000040 _ C4 41 FD: 28. B3, 00000780
; Note: Prefix bit or byte has no meaning in this context
vaddpd ymm0, ymm8, ymm14 ; 000005E5 _ C4 C1 BD: 58. C6
; Note: Prefix bit or byte has no meaning in this context
vsubpd ymm4, ymm4, ymmword ptr [r11+500H] ; 00000218 _ C4 C1 DD: 5C. A3, 00000500
Possible feature: with the presence of this option LOCAL values decared in a PROC are automatically initialised to zero?
Sorry to be a pain....
First the bugs:
vpsllq ymm11, ymm11, xmm0
vpsllq zmm11, zmm11, xmm0
is not assembling. The Intel manual and ML64 say this is OK.
ML64:
vpmuludq ymm8, ymm6, ymmword ptr [r11+520H] ; 392F _ C4 41 4D: F4. 83, 00000520
vpsrlq ymm9, ymm7, xmmword ptr [r11+2C0H] ; 3A13 _ C4 41 45: D3. 8B, 000002C0
HJWASM:
; Note: Prefix bit or byte has no meaning in this context
vpmuludq ymm8, ymm6, ymmword ptr [rbx+520H] ; 3930 _ C4 61 CD: F4. 83, 00000520
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm7, xmmword ptr [rbx+2C0H] ; 3A14 _ C4 61 C5: D3. 8B, 000002C0
Note that 'r11' turned into 'rbx'
ML64:
vptest ymm8, ymm6 ; 3FC2 _ C4 62 7D: 17. C6
HJWASM:
vptest ymm8, ymm14 ; 3FC7 _ C4 42 7D: 17. C6
Now some oddities:
ML64:
vpsrlq ymm9, ymm7, 3 ; 38B8 _ C5 B5: 73. D7, 03
HJWASM:
; Note: Prefix bit or byte has no meaning in this context
vpsrlq ymm9, ymm7, 3 ; 38B8 _ C4 E1 B5: 73. D7, 03
ML64 assembled this into one fewer byte.
vextractf128 is swapping src and dest register numbers:
vextractf128 xmm10,ymm0,1
encodes as:
C4 63 7D 19 D0 01 vextractf128 xmm0,ymm10,1
It would be awesome if Jwasm would support the calling convention used on 64-bit Linux and MacOSX:
System V AMD64 ABI convention: http://www.x86-64.org/documentation.html
My primary reason to use Jwasm is source code portability. So far I'm using Jwasm for Win32, Win64, Linux32 and OSX32, but the calling convention for Linux64/OSX64 is so different from any of the supported calling conventions that implementing it via an invoke-macro is rather quirky.
Kind regards,
Terry
vpsllvd zmm15, zmm13, zmm7
assembles as
vpsllvd zmm15, zmm13, zmm15
GCC debug mode fixups:
reswords.c: In function ‘DumpResWords’:
reswords.c:1304:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
printf("\nitems in InstrTable[]: %u\n", sizeof(InstrTable) / sizeof(InstrTable[0]));
^
reswords.c:1306:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
sizeof(optable_idx) / sizeof(optable_idx[0]), INS_FIRST_1 + 1, sizeof(ResWordTable) / sizeof(ResWordTable[0]) - 1);
^
reswords.c:1306:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/safeseh.o safeseh.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/segment.o segment.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/simsegm.o simsegm.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/string.o string.c
gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/symbols.o symbols.c
symbols.c: In function ‘DumpSymbol’:
symbols.c:807:5: warning: format ‘%p’ expects argument of type ‘void *’, but argument 5 has type ‘union ’ [-Wformat=]
printf( "%-12s %16" I64_SPEC "X %02X %8p %c %8p %s\n", type, value, sym->mem_type, dir->e, sym->ispublic ? 'X' : ' ', sym->name, sym->name );
^
mov eax,HIGHWORD 80000000h appears to be leaving the top half of eax signed with 0xffff... this is wrong.
vmovdqa zmm1, ZMMWORD PTR abc
does not assemble, but
vmovdqa zmm1, YMMWORD PTR abc
does
vpbroadcastb xmm1, xmm2
Warning! W1027: file assume.obj(K:\HJWASM\SRC\assume.c): redefinition of _broadflags ignored
Warning! W1027: file assume.obj(K:\HJWASM\SRC\assume.c): redefinition of _decoflags ignored
Add additional / corrected debug information to object output to allow breakpoints to be set on source code lines which are SSE/AVX instructions from inside Visual Studio (or other debugger).
HJWASM produces different output than ml64, causing objconv to output messages like below (I can email the full objconv output if all examples are needed):
; Note: Prefix bit or byte has no meaning in this context
vpmuludq ymm10, ymm9, ymmword ptr [r11+560H] ; 3A73 _ C4 41 B5: F4. 93, 00000560
John says this should not be a problem, but....
I'm getting EXC_BAD_INSTRUCTION crashes on Mac OS X. Now, this could be caused by an incompatibility with objconv. My build process is to use HJWASM 32-bit on Windows. Then the object file is fed into objconv to create a Mach-O object file and finally linked on the Mac.
I have confirmed that the ML64 object file works in my build process and the HJWASM object file does not. I have not yet tried the HJWASM object file linked into a Windows executable.
Using the Nov. 18 version:
vpaddq ymm1, YMM_INIT_SV23
assembles, but should raise an error as only 2 arguments are supplied
.zmm directive will allow the use of avx512 instructions and registers zmm(0) or xmm > 15
These should generate: Error A2049: Invalid instruction operands
vblendvpd xmm0, xmm1, xmm2
vblendvpd xmm0, xmm1, m128
vblendvpd ymm0, ymm1, ymm2
vblendvpd ymm0, ymm1, m256
but dont (there should be 4 operands).
These should generate: Error A2209: Syntax error: , xmm1
vmaskmovps m128, xmm0
vmaskmovps m256, ymm0
vmaskmovpd xmm0, xmm1
vfnmadd231pd zmm27, zmm24, zmm23
assembles as
` 62 02 BD 40: BC. DF`
which disssembles to:
`vfnmadd231pd zmm27, zmm24, zmm31 `
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.