Re: [9fans] more on why vc can't produce amd64 executables

2013-08-22 Thread Bakul Shah
On Wed, 21 Aug 2013 17:44:03 EDT erik quanstrom quans...@quanstro.net wrote: i think a bug is setting inuxi8[i+4] = inuxi8[i] for 0=i4. mikro; diffy -c *.c diff -c /n/dump/2013/0821/sys/src/cmd/6l/obj.c obj.c /n/dump/2013/0821/sys/src/cmd/6l/obj.c:1455,1471 - obj.c:1455,1471 int i, c;

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-22 Thread erik quanstrom
i think a bug is setting inuxi8[i+4] = inuxi8[i] for 0=i4. mikro; diffy -c *.c diff -c /n/dump/2013/0821/sys/src/cmd/6l/obj.c obj.c /n/dump/2013/0821/sys/src/cmd/6l/obj.c:1455,1471 - obj.c:1455,1471 int i, c; for(i=0; i4; i++) { - c = find1(0x04030201L, i+1);

[9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread erik quanstrom
vc vlongs are broken for cast for example, _v2uc produces the code: acid; asm(_v2uc) _v2uc 0x5360MOVWrv+8(FP),R1 _v2uc+0x4 0x5364JMP (R31) _v2uc+0x8 0x5368AND $0xff,R1 i think this should be MOVWrv+12(FP),R1 JMP (R31) AND

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread Bakul Shah
On Wed, 21 Aug 2013 14:36:40 EDT erik quanstrom quans...@quanstro.net wrote: uvlong x; x = 0x012345678abcdefull; print((uchar)x %.2ux\n, (uchar)x); ... x = 0012345678abcdef (uchar)x ef You're casting a large int into a small int and this seems right. Just as

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread erik quanstrom
You're casting a large int into a small int and this seems right. Just as (uchar)0x1234 = 0x34 marshalling a 64-bit pointer in this way will lay down the bytes with the hi and lo reversed. Perhaps you meant to do *(uchar*)x? you're right. what was i thinking. still, pointers are

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread Bakul Shah
On Aug 21, 2013, at 11:57 AM, erik quanstrom quans...@quanstro.net wrote: You're casting a large int into a small int and this seems right. Just as (uchar)0x1234 = 0x34 marshalling a 64-bit pointer in this way will lay down the bytes with the hi and lo reversed. Perhaps you meant to do

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread erik quanstrom
How %p is treated is really upto the implementation but it should not crash since p is never dereferenced. Does this work? uintptr q; print(%p, q); no. if i change the print to print an integer, it still fails. in fact, it's really the indirect call in print that fails. this

Re: [9fans] more on why vc can't produce amd64 executables

2013-08-21 Thread erik quanstrom
#include u.h #include libc.h void f(void) { write(1, hello\n, 6); } void (*call)(void) = f; void main(void) { call(); exits(); } the asm is the same when compiled on any arch, ; acid 6.crash4-mips 6.crash4-mips:amd64 plan 9 executable /sys/lib/acid/port