From jkrell at elego.de Mon Mar 1 05:34:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 5:34:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301043402.65E792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 05:34:02 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: move e_test use down below definition, so it works From jkrell at elego.de Mon Mar 1 11:55:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:55:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105536.BA6F32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:55:36 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: VAL(filesize, CARDINAL) to fix compilation From jkrell at elego.de Mon Mar 1 11:56:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:56:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105614.DD2B52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:56:14 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: INTEGER just in case From jkrell at elego.de Mon Mar 1 11:57:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:57:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105754.A5D862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:57:54 Modified files: cm3/m3-libs/libm3/tests/os/src/: Tag: release_branch_cm3_5_8 OSTest.m3 Log message: from head: VAL(filesize, INTEGER) to fix compilation From jkrell at elego.de Mon Mar 1 13:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 13:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301125437.9F27D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 13:54:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: work in progress to inline all 64bit shifts (and then rotates) the 64bit shift code in particular in the AMD manual is around 6 instruction however before we do that: teach unOp about double shift (aka shift by ecx) not yet used, as these cases still call functions split up the double ops into separate functions for readability: not_double, add_double, add_double_immediate, etc. (not, negate, add, subtract, compare, immediate and not; bigger things like multiply/divide generate function calls at a higher level, currently; given that our complicated single precision divide was inlined, probably will inline that for double, probably multiple too; while the result is bloated, I like the idea of reducing hand.c, and longint use on 32bit targets maybe ok to bloat?) also goal to have less duplication of the various logic such as left vs. right vs. "signed" shift, the compares to 32, 64, etc. at least move the code into fewer functions also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split into something that seems less hoky. Part of the issue is that other than oNOT, and separate functions like swapOp, movOp, nothing is really "just loop over the parts" From jay.krell at cornell.edu Mon Mar 1 13:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Mar 2010 12:57:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100301125437.9F27D2474001@birch.elegosoft.com> References: <20100301125437.9F27D2474001@birch.elegosoft.com> Message-ID: attached btw, other than the commit mail, the changelog should have a clickable link. > Date: Mon, 1 Mar 2010 13:54:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/01 13:54:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 > > Log message: > work in progress to inline all 64bit shifts (and then rotates) > the 64bit shift code in particular in the AMD manual is around 6 instruction > > however before we do that: > > teach unOp about double shift (aka shift by ecx) > not yet used, as these cases still call functions > > split up the double ops into separate functions for readability: > not_double, add_double, add_double_immediate, etc. > (not, negate, add, subtract, compare, immediate and not; bigger > things like multiply/divide generate function calls at a higher level, currently; > given that our complicated single precision divide was inlined, probably will > inline that for double, probably multiple too; while the result is bloated, > I like the idea of reducing hand.c, and longint use on 32bit targets > maybe ok to bloat?) > > also goal to have less duplication of the various logic such > as left vs. right vs. "signed" shift, the compares to 32, 64, etc. > at least move the code into fewer functions > > also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split > into something that seems less hoky. Part of the issue is that > other than oNOT, and separate functions like swapOp, movOp, nothing is really > "just loop over the parts" > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 1 15:25:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 15:25:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301142522.44AD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 15:25:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: fix and slightly extend From jkrell at elego.de Tue Mar 2 13:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125012.EDEEE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:50:12 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: case and whitespace From jkrell at elego.de Tue Mar 2 13:52:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:52:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125229.A8E4B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:52:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: somewhat consolidate shifting code no more "binOpWithShiftCount" inline all 64bit shifts, even when no constants involved (constants get inlined better) worst cases: shift right 64 (from the AMD manual): 00002217: 0F AD D3 shrd ebx,edx,cl 0000221A: D3 EA shr edx,cl 0000221C: F6 C1 20 test cl,20h 0000221F: 74 04 je 00002225 00002221: 8B DA mov ebx,edx 00002223: 33 D2 xor edx,edx 00002225: shift left 64 (from the AMD manual): 0000244B: 0F A5 DA shld edx,ebx,cl 0000244E: D3 E3 shl ebx,cl 00002450: F6 C1 20 test cl,20h 00002453: 74 04 je 00002459 00002455: 8B D3 mov edx,ebx 00002457: 33 DB xor ebx,ebx 00002459: Those sequences are quite subtle. I'm not sure I understand. Shift by between 32 and 63: The "wrong" register is shifted, but it is done modulo-32, so the correct result is had, in the "wrong" register then the register is moved to its correct place. That is: edx:eax << 33 is straightforwardly, after testing if the shift count is >32: edx = eax edx <<= 1 (shift count - 32) eax = 0 however the above does the shift before the move, since the modulo makes it correct: eax <<= (33 % 32) which is eax <<= 1 edx = eax eax = 0 The way it detects >=32 is very subtle to me. It checks if the 32 bit is set. If it is not set, the work is deemed done. Any value in 33-64 inclusive has it set, and gets shifted an extra 32, via mov and xor. Any value in 0-31 has it clear, done. The case of 32 exactly works with the first two instructions. I guess. I didn't come up with this, it is in the AMD optimization manual. wierdo shift 32: (no change) 00006CD4: 83 F9 00 cmp ecx,0 00006CD7: 7D 0F jge 00006CE8 00006CD9: F7 D9 neg ecx 00006CDB: 83 F9 20 cmp ecx,20h 00006CDE: 7D 04 jge 00006CE4 00006CE0: D3 EB shr ebx,cl 00006CE2: EB 0B jmp 00006CEF 00006CE4: 33 DB xor ebx,ebx 00006CE6: EB 07 jmp 00006CEF 00006CE8: 83 F9 20 cmp ecx,20h 00006CEB: 7D F7 jge 00006CE4 00006CED: D3 E3 shl ebx,cl 00006CEF: wierdo shift 64: 000071E9: 83 F9 00 cmp ecx,0 000071EC: 7D 1D jge 0000720B 000071EE: F7 D9 neg ecx 000071F0: 83 F9 40 cmp ecx,40h 000071F3: 7D 10 jge 00007205 000071F5: 0F AD F3 shrd ebx,esi,cl 000071F8: D3 EE shr esi,cl 000071FA: F6 C1 20 test cl,20h 000071FD: 74 04 je 00007203 000071FF: 8B DE mov ebx,esi 00007201: 33 F6 xor esi,esi 00007203: EB 19 jmp 0000721E 00007205: 33 DB xor ebx,ebx 00007207: 33 F6 xor esi,esi 00007209: EB 13 jmp 0000721E 0000720B: 83 F9 40 cmp ecx,40h 0000720E: 7D F5 jge 00007205 00007210: 0F A5 DE shld esi,ebx,cl 00007213: D3 E3 shl ebx,cl 00007215: F6 C1 20 test cl,20h 00007218: 74 04 je 0000721E 0000721A: 8B F3 mov esi,ebx 0000721C: 33 DB xor ebx,ebx 0000721E: as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) We might as well first compare to -64 before the negate, same instruction count, more obviously correct. there are a few extra instructions in wierd shift 64, the parts that shift by more than 32 or more than 64 have common pieces that can be shared ("tail merged") and there is a branch to a jmp We should see about optimizing the wierd shift 64 case. A few instructions can easily be saved. From jkrell at elego.de Tue Mar 2 13:59:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:59:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125931.619312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:59:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove m3_shift64, which for the record was: uint64 __stdcall m3_shift64(uint64 a, int b) { if (b >= 64 || b <= -64) a = 0; else if (b > 0) a <<= b; else if (b < 0) a >>= -b; return a; } _m3_shift64 at 12: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 00000006: 8D 41 3F lea eax,[ecx+3Fh] 00000009: 83 F8 7E cmp eax,7Eh 0000000C: 77 1C ja 0000002A 0000000E: 8B 45 08 mov eax,dword ptr [ebp+8] 00000011: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000014: 85 C9 test ecx,ecx 00000016: 7E 07 jle 0000001F 00000018: E8 00 00 00 00 call __allshl 0000001D: EB 0F jmp 0000002E 0000001F: 7D 0D jge 0000002E 00000021: F7 D9 neg ecx 00000023: E8 00 00 00 00 call __aullshr 00000028: EB 04 jmp 0000002E 0000002A: 33 C0 xor eax,eax 0000002C: 33 D2 xor edx,edx 0000002E: 5D pop ebp 0000002F: C2 0C 00 ret 0Ch From jay.krell at cornell.edu Tue Mar 2 14:18:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Mar 2010 13:18:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100302125229.A8E4B2474001@birch.elegosoft.com> References: <20100302125229.A8E4B2474001@birch.elegosoft.com> Message-ID: roughly the attached, though I know the case/space diff is also there It's pretty hard to find this stuff via cvsweb/changelog/etc..... - Jay > Date: Tue, 2 Mar 2010 13:52:29 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/02 13:52:29 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.i3 Stackx86.m3 > > Log message: > somewhat consolidate shifting code > > no more "binOpWithShiftCount" > > inline all 64bit shifts, even when no constants involved > (constants get inlined better) > > worst cases: > > shift right 64 (from the AMD manual): > 00002217: 0F AD D3 shrd ebx,edx,cl > 0000221A: D3 EA shr edx,cl > 0000221C: F6 C1 20 test cl,20h > 0000221F: 74 04 je 00002225 > 00002221: 8B DA mov ebx,edx > 00002223: 33 D2 xor edx,edx > 00002225: > > shift left 64 (from the AMD manual): > 0000244B: 0F A5 DA shld edx,ebx,cl > 0000244E: D3 E3 shl ebx,cl > 00002450: F6 C1 20 test cl,20h > 00002453: 74 04 je 00002459 > 00002455: 8B D3 mov edx,ebx > 00002457: 33 DB xor ebx,ebx > 00002459: > > Those sequences are quite subtle. > I'm not sure I understand. > Shift by between 32 and 63: > The "wrong" register is shifted, but it is done modulo-32, > so the correct result is had, in the "wrong" register > then the register is moved to its correct place. > That is: > edx:eax << 33 > is straightforwardly, after testing if the shift count is >32: > edx = eax > edx <<= 1 (shift count - 32) > eax = 0 > however the above does the shift before the move, > since the modulo makes it correct: > eax <<= (33 % 32) which is eax <<= 1 > edx = eax > eax = 0 > > The way it detects >=32 is very subtle to me. > It checks if the 32 bit is set. > If it is not set, the work is deemed done. > Any value in 33-64 inclusive has it set, and gets shifted an extra 32, > via mov and xor. > Any value in 0-31 has it clear, done. > The case of 32 exactly works with the first two instructions. > > I guess. > I didn't come up with this, it is in the AMD optimization manual. > > wierdo shift 32: (no change) > 00006CD4: 83 F9 00 cmp ecx,0 > 00006CD7: 7D 0F jge 00006CE8 > 00006CD9: F7 D9 neg ecx > 00006CDB: 83 F9 20 cmp ecx,20h > 00006CDE: 7D 04 jge 00006CE4 > 00006CE0: D3 EB shr ebx,cl > 00006CE2: EB 0B jmp 00006CEF > 00006CE4: 33 DB xor ebx,ebx > 00006CE6: EB 07 jmp 00006CEF > 00006CE8: 83 F9 20 cmp ecx,20h > 00006CEB: 7D F7 jge 00006CE4 > 00006CED: D3 E3 shl ebx,cl > 00006CEF: > > wierdo shift 64: > 000071E9: 83 F9 00 cmp ecx,0 > 000071EC: 7D 1D jge 0000720B > 000071EE: F7 D9 neg ecx > 000071F0: 83 F9 40 cmp ecx,40h > 000071F3: 7D 10 jge 00007205 > 000071F5: 0F AD F3 shrd ebx,esi,cl > 000071F8: D3 EE shr esi,cl > 000071FA: F6 C1 20 test cl,20h > 000071FD: 74 04 je 00007203 > 000071FF: 8B DE mov ebx,esi > 00007201: 33 F6 xor esi,esi > 00007203: EB 19 jmp 0000721E > 00007205: 33 DB xor ebx,ebx > 00007207: 33 F6 xor esi,esi > 00007209: EB 13 jmp 0000721E > 0000720B: 83 F9 40 cmp ecx,40h > 0000720E: 7D F5 jge 00007205 > 00007210: 0F A5 DE shld esi,ebx,cl > 00007213: D3 E3 shl ebx,cl > 00007215: F6 C1 20 test cl,20h > 00007218: 74 04 je 0000721E > 0000721A: 8B F3 mov esi,ebx > 0000721C: 33 DB xor ebx,ebx > 0000721E: > > as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) > We might as well first compare to -64 before the negate, same instruction count, more > obviously correct. > there are a few extra instructions in wierd shift 64, the parts that > shift by more than 32 or more than 64 have common pieces that > can be shared ("tail merged") and there is a branch to a jmp > > We should see about optimizing the wierd shift 64 case. > A few instructions can easily be saved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Tue Mar 2 14:46:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:46:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134623.1FB6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:46:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: source of the new bits in shift double must a register, can't be memory, so remove two lines that handle the memory case From jkrell at elego.de Tue Mar 2 14:48:49 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:48:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134849.6DD6B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:48:49 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: 'shift_double_tail' ended up with only one caller -- 'shift_double_ecx' -- inline it here (these are small functions, point is readability, not perf) From jkrell at elego.de Tue Mar 2 14:52:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:52:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302135258.352D82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:52:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: some tersification, not sure this is a good idea -- omit types in VAR, initialize in VAR instead of body From jkrell at elego.de Tue Mar 2 15:14:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141404.128992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:04 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 TIntN.i3 TWordN.i3 TWordN.m3 Log message: avoid runtime error (range error) in compiler when user shifts by too large of a number leave it as a warning, generate unoptimized code, and let the runtime error occur in user's program From jkrell at elego.de Tue Mar 2 15:14:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141434.4A5B42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:34 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: whitespace to my liking From jkrell at elego.de Wed Mar 3 10:21:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:21:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092142.7B7862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it From jkrell at elego.de Wed Mar 3 10:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092303.41FDD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> in zero_n; gcc backend implements it incorrectly and it is never used From jkrell at elego.de Wed Mar 3 12:09:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:09:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303110910.8DB8F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:09:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: extend test case (a bit annoyingly long already) attempting to insert/extract upper bits I haven't yet extended the bit offsets before I get there, this extension already is exhibiting two behaviors that need further investigation, and is therefore not quite as extended as intended (the commenting out of flipA) in the 32bit insert, I get a subrange error if I allow the flipA Perhaps I just don't understand something. in the 64bit insert, I get an error in the backend if I allow flipA and the code looks a little wrong; it is having trouble allocating registers/temps will test with gcc for one thing and with the release branch the 64bit problem doesn't seem to do with 64bits so much as "complex" expressions in function calls (sounds wrong, but no matter, I'll investigate) From jkrell at elego.de Wed Mar 3 12:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303112525.6BFCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: try make it more portable, and now also reduce runtime significantly by removing coverage that should be redundant From jkrell at elego.de Wed Mar 3 12:31:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:31:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303113140.111092474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:31:39 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: more portability, more shrinkage From jkrell at elego.de Wed Mar 3 12:44:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:44:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114404.568562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:44:04 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: more portable From jkrell at elego.de Wed Mar 3 12:45:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:45:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114545.5705C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:45:45 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: -lp and -less-portable synonyms for -'include-less-portable-output From jkrell at elego.de Wed Mar 3 12:47:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:47:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114703.EA9F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:47:03 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:48:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:48:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114842.EAA0B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:48:42 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115437.4B8842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:54:37 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 12:56:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:56:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115640.C3CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:56:40 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 13:05:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:05:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120553.8364B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:05:53 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: store result in INTEGER instead of CARDINAL to fix the one problem From jkrell at elego.de Wed Mar 3 13:08:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:08:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120822.1E66F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:08:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update amd64 output From jkrell at elego.de Wed Mar 3 13:10:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:10:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121035.627AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:10:35 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: add ASSERT FALSE after a new problem test p227 finds if you enable flipA in the LONGINT part of TestInsert From jkrell at elego.de Wed Mar 3 13:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121455.71FC02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:14:55 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: don't bother printing the 0 cases that we an just assert: wow that cuts things down! From jkrell at elego.de Wed Mar 3 13:17:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:17:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121710.A2D102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:17:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: oops From jkrell at elego.de Wed Mar 3 13:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121809.298F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:18:09 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update (was small because of assertion failure, alas) From jkrell at elego.de Wed Mar 3 13:19:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:19:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121956.76C162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:19:56 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Log message: update output From jkrell at elego.de Wed Mar 3 14:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 14:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303131128.2F6D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 14:11:27 Modified files: cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.m3 Log message: untested port small fix from head for initializing longint, see revision 1.34 From hosking at cs.purdue.edu Wed Mar 3 16:57:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 10:57:32 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100303092142.7B7862474001@birch.elegosoft.com> References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 3 17:02:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 11:02:36 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/03 10:21:42 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> zero_n is incorrect and never used, put gcc_assert(0) in it > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Wed Mar 3 17:44:58 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:44:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164458.6DE562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:44:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Detangle spaghetti code: flags are evil! Verbosity is sometimes the essence of clarity when it permits context-freedom. From hosking at elego.de Wed Mar 3 17:49:28 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164928.7B6322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:49:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Make it compile! From hosking at elego.de Wed Mar 3 17:53:51 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:53:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303165351.7B4F02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:53:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Reorganise slightly so diffs work more nicely with past versions. From hosking at elego.de Wed Mar 3 18:23:21 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172321.4EEC52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:23:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Let's respect the definition of BYTESIZE (in case it ever were to change). Also, why the nasty constant folding in index_address? Let gcc's constant folders take care of it (inside m3_build2). From hosking at elego.de Wed Mar 3 18:24:14 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:24:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172415.06D6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:24:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Fix warning. From jay.krell at cornell.edu Thu Mar 4 00:45:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Mar 2010 23:45:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Thu Mar 4 04:15:49 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 4 Mar 2010 4:15:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304031550.08E012474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/04 04:15:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Cleanup. Fix m3cg_zero_n. From hosking at cs.purdue.edu Thu Mar 4 04:29:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 22:29:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:31:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:31:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote:Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 07:46:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 01:46:53 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:57:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:57:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> , <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> Message-ID: It is still not possible to test. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Thu, 4 Mar 2010 01:46:53 -0500 CC: m3commit at elegosoft.com To: jay.krell at cornell.edu I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 08:16:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 07:16:20 +0000 Subject: [M3commit] m3_build vs. build in parse.c? Message-ID: Why use one vs. the other? It appears that they are equivalent *except* that m3_build attempts to optimize, but falls back to build if it can't. That is, m3_build calls fold_build. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 08:58:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 02:58:30 -0500 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: References: Message-ID: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. On 4 Mar 2010, at 02:16, Jay K wrote: > Why use one vs. the other? > It appears that they are equivalent *except* that m3_build attempts to optimize, > but falls back to build if it can't. > > That is, m3_build calls fold_build. > > - Jay > > > > From jay.krell at cornell.edu Thu Mar 4 09:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 08:46:06 +0000 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> References: , <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> Message-ID: Why not always call m3_build? Why ever call build? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 4 Mar 2010 02:58:30 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] m3_build vs. build in parse.c? > > So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. > > On 4 Mar 2010, at 02:16, Jay K wrote: > > > Why use one vs. the other? > > It appears that they are equivalent *except* that m3_build attempts to optimize, > > but falls back to build if it can't. > > > > That is, m3_build calls fold_build. > > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Mar 4 12:43:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 04 Mar 2010 12:43:52 +0100 Subject: [M3commit] lost commit messages: Fwd: 4 Forwarded Messages Message-ID: <20100304124352.acni7mp0nk8k0wk4@mail.elegosoft.com> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:57:48 +0100 Size: 2468 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:55:52 +0100 Size: 2523 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:51:37 +0100 Size: 2452 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:50:37 +0100 Size: 2518 URL: From jkrell at elego.de Thu Mar 4 13:57:24 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 13:57:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304125724.807162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 13:57:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: eliminate calls to set_member and set_singleton the unoptimized code for set_member is decent, though not nearly as good as m3back (m3back uses bts and bt) the code for set_singleton never seems particularly great but ok I tried a lot with array_ref, and bit_field ref, no luck the use of stabilize_reference (or build(save_expr)) does help In particular in set_singleton, I can't get the compiler to "or into memory", never as good even when optimized as optimized C. The C compiler's best: void set_singleton(unsigned* a, unsigned b) { a[b / 32] |= (1 << (b % 32)); } pushl %ebp movl %esp, %ebp movl 12(%ebp), %ecx movl 8(%ebp), %eax movl %ecx, %edx andl $31, %ecx shrl $5, %edx leal (%eax,%edx,4), %edx << not able to get this from cm3cg movl $1, %eax sall %cl, %eax orl %eax, (%edx) << not able to get this from cm3cg popl %ebp ret I can never get it to use lea with both a scale and an address. I will try a bit more, but this version should do. In particular I was using bit_field_ref with size 1, setting it to 1, maybe a full word will work better. This variation also has an advantage over some in that it shouldn't break pickles. This might be considered a significant size deoptimization and better off before, calling a function. tested on LINUXLIBC6 (so far) From jkrell at elego.de Thu Mar 4 14:19:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 14:19:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304131906.E94622474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 14:19:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove set_singleton and set_member From jkrell at elego.de Thu Mar 4 15:41:22 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 15:41:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304144122.CF96B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 15:41:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: stylistic variation on previous From rodney_bates at lcwb.coop Thu Mar 4 21:45:12 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 04 Mar 2010 14:45:12 -0600 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <4B901BD8.10403@lcwb.coop> Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. I am with Tony on this one. Well-designed code has always had places where it will handle a more general input space than current use-cases demand. Always removing everything from what is handled reflects the view that a program is a one-time thing that never changes. Putting in some things that follow a consistent general pattern reflects the view that a program is an evolving thing. Excepting a very few programs that are either trivial or very little-used, the latter assumption is always the correct one. Of course, you can't put everything imaginable in. But things that are part of a general pattern are good candidates. Nobody could _ever_ design very useful code, if not following this principal. I once, in my very first job, had to rework a big test driver written in such a way that it handled exactly the set of test cases that had been originally specified and not a thing more. Nobody could add any new cases as things evolved. The internal structure bore no resemblance to the pattern of the inputs. I could only throw it all out except for some low-level routines and start over. > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by > m3middle, so let's support it and not get bitten in the arse if/when > m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or > right to left, I looked at these two examples and decided they can't > both be correct. > > - Jay > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > From jkrell at elego.de Thu Mar 4 23:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225038.01F032474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:50:37 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go a back a version to 1.88 From jkrell at elego.de Thu Mar 4 23:52:57 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:52:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225257.BA75F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:52:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: back to versoin 1.123 pending more testing From jay.krell at cornell.edu Fri Mar 5 01:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 00:50:28 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100304225257.BA75F2474001@birch.elegosoft.com> References: <20100304225257.BA75F2474001@birch.elegosoft.com> Message-ID: This was probably fine. I had a failure on a machine but that was possibly some uncommited version. I also had some version go through ok on LINUXLIBC6 and some version on AMD64_DARWIN so the approach is ok. To be certain I reverted it for now. Will probably back something within 24 hours. I'll maybe test SOLgnu and PPC_DARWIN as well. - Jay ---------------------------------------- > Date: Thu, 4 Mar 2010 23:52:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/04 23:52:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > back to versoin 1.123 pending more testing > From jkrell at elego.de Fri Mar 5 11:25:21 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 11:25:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305102521.7CBCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 11:25:21 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: small workaround wrt M3_PROFILING for older cm3 and/or other m3quake users other than cm3 From jkrell at elego.de Fri Mar 5 12:16:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:16:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305111649.CD4AF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:16:49 Modified files: cm3/scripts/python/: pylib.py Log message: don't put mklib in boot archives just because the overly simple makefile can only link one executable; don't include --32 on PPC_LINUX assembler invocations, it doesn't like it From jkrell at elego.de Fri Mar 5 12:56:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:56:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305115628.4F8B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:56:28 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC64_DARWIN Log message: 'PPC.common' => 'PPC64.common' From jkrell at elego.de Fri Mar 5 13:19:02 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:19:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305121902.4D7792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:19:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: #if __APPLE__ && __x86_64__ => __APPLE__ && __LP64__ so that is also works on PPC64 From jkrell at elego.de Fri Mar 5 13:45:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:45:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124527.D0EA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:45:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again: remove set_member and set_singleton From jkrell at elego.de Fri Mar 5 13:48:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:48:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124817.C66CB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:48:17 Modified files: cm3/scripts/python/: pylib.py Log message: add -arch ppc64 on PPC64_DARWIN, like -arch x86_64 on AMD64_DARWIN From jkrell at elego.de Fri Mar 5 13:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125132.72FE32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:51:32 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. The first two platforms fail to link due to references to these functions. Presumably the last too. I know the plan is to fallback to locks somewhere, but I don't think they have materialized yet. From jkrell at elego.de Fri Mar 5 13:53:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:53:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125358.707872474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:53:58 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. From jkrell at elego.de Fri Mar 5 13:54:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:54:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125444.8D6CE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:54:44 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadApple.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. (same problem and fix as RTSignalC.c) From jkrell at elego.de Fri Mar 5 13:57:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:57:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125712.A4F8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:57:12 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadInterix.c Log message: not used: ThreadInterix.c From jkrell at elego.de Fri Mar 5 14:09:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305130939.75E332474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:09:39 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: decrease PPC_DARWIN jmpbuf align to 32 add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:11:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:11:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131147.559DB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:11:47 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: slightly different style From jkrell at elego.de Fri Mar 5 14:16:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:16:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131629.36D552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:16:29 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131713.EB0262474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:17:13 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add PPC64_DARWIN (only needed for cross builds I believe, but that's what I did so far) From jay.krell at cornell.edu Fri Mar 5 14:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 13:57:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4B901BD8.10403@lcwb.coop> References: <20100303092142.7B7862474001@birch.elegosoft.com>, ,,, , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I understand that. I often am "like that". But we are our own consumers. The code has probably been unused a long time, but I didn't check. We can put it in when we need it. http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it - Jay > Date: Thu, 4 Mar 2010 14:45:12 -0600 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay K wrote: > > Maybe remove it instead? Unused suggests untested, not working. > > I am with Tony on this one. Well-designed code has always had places where > it will handle a more general input space than current use-cases demand. > > Always removing everything from what is handled reflects the view that a > program is a one-time thing that never changes. Putting in some things > that follow a consistent general pattern reflects the view that a program > is an evolving thing. Excepting a very few programs that are either trivial > or very little-used, the latter assumption is always the correct one. > > Of course, you can't put everything imaginable in. But things that are part > of a general pattern are good candidates. Nobody could _ever_ design very > useful code, if not following this principal. > > I once, in my very first job, had to rework a big test driver written in > such a way that it handled exactly the set of test cases that had been > originally specified and not a thing more. Nobody could add any new cases > as things evolved. The internal structure bore no resemblance to the > pattern of the inputs. I could only throw it all out except for some > low-level routines and start over. > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > It turns out not actually to be used by m3front. But it is defined by > > m3middle, so let's support it and not get bitten in the arse if/when > > m3front ever uses it. > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > I don't see where it is used. > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > (in m3back). > > The parameters are being passed to memset in the wrong order. > > Compare it to m3cg_zero. > > I was actually looking to see if parameters are left to right or > > right to left, I looked at these two examples and decided they can't > > both be correct. > > > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > To: hosking at cs.purdue.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Please say how this is broken. > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > Huh? I see it in the front-end! > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 15:12:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:12:55 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305125132.72FE32474001@birch.elegosoft.com> References: <20100305125132.72FE32474001@birch.elegosoft.com> Message-ID: I think PPC has the necessary instructions. Does gcc not generate them? Maybe need a -arch parameter to get it to use them. On 5 Mar 2010, at 13:51, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/05 13:51:32 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > > Log message: > Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. > The first two platforms fail to link due to references to these > functions. Presumably the last too. I know the plan is to fallback to > locks somewhere, but I don't think they have materialized yet. From hosking at elego.de Fri Mar 5 15:16:38 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 5 Mar 2010 15:16:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305141638.827582474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/05 15:16:38 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: Cleaner! From hosking at cs.purdue.edu Fri Mar 5 15:17:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:17:21 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I already fixed it! On 5 Mar 2010, at 08:57, Jay K wrote: > I understand that. I often am "like that". > But we are our own consumers. The code has probably been unused a long time, but I didn't check. > We can put it in when we need it. > http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it > > > - Jay > > > > Date: Thu, 4 Mar 2010 14:45:12 -0600 > > From: rodney_bates at lcwb.coop > > To: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > Jay K wrote: > > > Maybe remove it instead? Unused suggests untested, not working. > > > > I am with Tony on this one. Well-designed code has always had places where > > it will handle a more general input space than current use-cases demand. > > > > Always removing everything from what is handled reflects the view that a > > program is a one-time thing that never changes. Putting in some things > > that follow a consistent general pattern reflects the view that a program > > is an evolving thing. Excepting a very few programs that are either trivial > > or very little-used, the latter assumption is always the correct one. > > > > Of course, you can't put everything imaginable in. But things that are part > > of a general pattern are good candidates. Nobody could _ever_ design very > > useful code, if not following this principal. > > > > I once, in my very first job, had to rework a big test driver written in > > such a way that it handled exactly the set of test cases that had been > > originally specified and not a thing more. Nobody could add any new cases > > as things evolved. The internal structure bore no resemblance to the > > pattern of the inputs. I could only throw it all out except for some > > low-level routines and start over. > > > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > It turns out not actually to be used by m3front. But it is defined by > > > m3middle, so let's support it and not get bitten in the arse if/when > > > m3front ever uses it. > > > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > > > I don't see where it is used. > > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > > (in m3back). > > > The parameters are being passed to memset in the wrong order. > > > Compare it to m3cg_zero. > > > I was actually looking to see if parameters are left to right or > > > right to left, I looked at these two examples and decided they can't > > > both be correct. > > > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > > To: hosking at cs.purdue.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Please say how this is broken. > > > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > > > Huh? I see it in the front-end! > > > > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 15:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305143429.4B9522474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:34:29 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: oops I was fiddling with bytes and bits and how to annotate them and I got it wrong: alignment is 32, 32 bits From jkrell at elego.de Fri Mar 5 15:46:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305144640.E147F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:46:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: no ODBC on PPC64_DARWIN From jkrell at elego.de Fri Mar 5 15:51:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:51:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305145148.851592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:51:47 Modified files: cm3/scripts/python/: pylib.py Log message: detect PPC64_DARWIN, from 32bit Python, by comparing ppc970 to ppc970 From jkrell at elego.de Fri Mar 5 16:00:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:00:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150035.B69F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:00:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: PPC64_DARWIN 10.4: no X, no Trestle: we need to teach cm3 to sniff the directories/files and their architectures From jkrell at elego.de Fri Mar 5 16:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150658.81EB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:06:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:09:19 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:09:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150919.85D9E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:09:19 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:16:15 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:16:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305151615.2DEEA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:16:15 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: fix typo, so it works on big endian systems, such as PPC64_DARWIN (and PPC_DARWIN, PPC_LINUX, SOLgnu, SPARC32_LINUX, etc.) From jkrell at elego.de Fri Mar 5 16:22:06 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:22:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152206.117CC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:22:06 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: replace portable output with correct output From jkrell at elego.de Fri Mar 5 16:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152514.247902474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:25:14 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm32 stdout.pgm64 Removed files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian32 stdout.pgm-little_endian64 Log message: it turns out this isn't (currently) endian specific, just wordsize specific (PPC64_DARWIN output matches AMD64_DARWIN) From jay.krell at cornell.edu Fri Mar 5 16:32:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 15:32:00 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305141638.827582474001@birch.elegosoft.com> References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear I suppose for alignment I could say bits = 1. - Jay > Date: Fri, 5 Mar 2010 15:16:38 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/05 15:16:38 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > Cleaner! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 17:11:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 11:11:41 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: <343D34B0-D380-4FEF-AD8B-B2DB03E6A8F3@cs.purdue.edu> Why not multiply by some appropriate size. x * Int32.size, etc.? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Mar 2010, at 10:32, Jay K wrote: > sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear > I suppose for alignment I could say bits = 1. > > - Jay > > > > Date: Fri, 5 Mar 2010 15:16:38 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/05 15:16:38 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > Log message: > > Cleaner! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 22:11:26 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:11:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211126.9928B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:11:26 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: do it the usual way: * Word8.size; Word32.size From jkrell at elego.de Fri Mar 5 22:17:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:17:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211729.31D422474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:17:29 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertToCygwinPath' => 'ConvertToCygwinPath' (private to public) so that make-dist.py works From jkrell at elego.de Fri Mar 5 22:18:48 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:18:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211848.6ABD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:18:48 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertFromCygwinPath' => 'ConvertFromCygwinPath' (private to public) just to match ConvertToCygwinPath (not used) From jkrell at elego.de Sat Mar 6 12:02:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:02:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306110201.94DED2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:02:01 Added files: cm3/m3-sys/m3tests/src/p2/p231/: m3makefile Main.m3 Log message: small test case split out of p227 that shows something m3back currently fails to compile From jkrell at elego.de Sat Mar 6 12:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306111830.94AB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:18:30 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm Log message: big endian output (and really we have to compare this with an older compiler, make sure replacement of set_singleton hasn't changed which bits are set -- pickle compatibility) From jkrell at elego.de Sat Mar 6 12:23:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:23:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112338.8F4482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:23:38 Removed files: cm3/m3-sys/m3tests/src/p2/p225/: stderr.build stdout.build stderr.pgm Log message: shouldn't need the zero sized files any longer From jkrell at elego.de Sat Mar 6 12:26:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:26:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112629.ED4102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:26:29 Modified files: cm3/m3-sys/m3tests/src/p2/p231/: Main.m3 Log message: comment as to what the test is for From jkrell at elego.de Sat Mar 6 13:38:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306123838.6C3B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:38:38 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: some cleanup ahead of other fixes (the free_temp problem) in particular: - replace RegSet{} with AllRegisters This makes some code a little simpler. RegSet{} does mean "anything" and we can capture that pretty faithfully via AllRegisters. We are lucky we don't have to allocate float registers though, that might call for something a little different - in some places I was extra cautious and ran the same old code for size = 1 (data fitting in a single register), as well there are places that assume the largest size is 2 Generalize *some* of that to loop over whatever size, doing the "same" thing at each step. There are still places that say like "if foo[0] and foo[size - 1]" which works as long as size can only be 1 or 2. - fix warning about unreachable code after assert false (the unused, untested zero_n) From jay.krell at cornell.edu Sat Mar 6 13:39:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:39:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306123838.6C3B22474001@birch.elegosoft.com> References: <20100306123838.6C3B22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 6 Mar 2010 13:38:38 +0000 > To: m3commit > From: jkrell > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:38:38 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > some cleanup ahead of other fixes (the free_temp problem) > > in particular: > - replace RegSet{} with AllRegisters > This makes some code a little simpler. > RegSet{} does mean "anything" and we can > capture that pretty faithfully via AllRegisters. > We are lucky we don't have to allocate float registers though, > that might call for something a little different > > - in some places I was extra cautious and ran > the same old code for size = 1 (data fitting in a single register), > as well there are places that assume the largest size is 2 > Generalize *some* of that to loop over whatever size, doing > the "same" thing at each step. > > There are still places that say like "if foo[0] and foo[size - 1]" > which works as long as size can only be 1 or 2. > > - fix warning about unreachable code after assert false (the unused, > untested zero_n) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 6 13:55:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306125552.552592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:55:52 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 only call free_temp for operandPart = 0 Better might be to, like, remove some/many of the loops and teach more of the code to deal with "multi part operands" (or multi register operands). From jay.krell at cornell.edu Sat Mar 6 13:56:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:56:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306125552.552592474001@birch.elegosoft.com> References: <20100306125552.552592474001@birch.elegosoft.com> Message-ID: very small diff inline: Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.112 diff -u -r1.112 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:38:38 -0000 1.112 +++ Stackx86.m3 6 Mar 2010 12:54:37 -0000 @@ -197,7 +197,9 @@ IF op.loc = OLoc.mem THEN IF op.mvar.var.stack_temp THEN - t.parent.free_temp(op.mvar.var); + IF operandPart = 0 THEN + t.parent.free_temp(op.mvar.var); + END; ELSE t.reguse[r].last_store := op.mvar; END > Date: Sat, 6 Mar 2010 13:55:52 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:55:52 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 > only call free_temp for operandPart = 0 > > Better might be to, like, remove some/many of the loops and > teach more of the code to deal with "multi part operands" > (or multi register operands). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 7 03:32:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:32:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023243.806FA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:32:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: 'ulong' => 'size_t' where it is easy (more coming) From jkrell at elego.de Sun Mar 7 03:33:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:33:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023327.12FAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:33:26 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove check for older Microsoft compiler with no __int64 support (16bit compiler) From jkrell at elego.de Sun Mar 7 03:34:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:34:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023450.6F4212474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:34:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: assume but verify that uint is 32bits From jkrell at elego.de Sun Mar 7 03:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023531.EEFAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:35:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add comment From jkrell at elego.de Sun Mar 7 03:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023704.88E182474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:37:04 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: maybe a safer check, in case of overflow From jkrell at elego.de Sun Mar 7 03:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307024743.D13762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:47:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: this part of the test is 32bit specific From jkrell at elego.de Sun Mar 7 03:54:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:54:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307025406.5C6C92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:54:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'ulong' => 'size_t' (much of this going away shortly) From jkrell at elego.de Sun Mar 7 04:01:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:01:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030112.BA0DA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:01:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'size_t' => 'ulong' to fix gcc printf warnings From jkrell at elego.de Sun Mar 7 04:06:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:06:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030630.9093B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:06:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: collect timings on other platforms, albeit low resolution From jkrell at elego.de Sun Mar 7 04:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032021.E1DFF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:20:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: replace set_range with set_range_new set_range_new is never significantly slower and sometimes significantly faster, depending on architecture, compiler, optimization flags optimization definitely helps this code a lot sometimes, e.g. old is 9 seconds unoptimized on sparc64, new is 3 seconds unoptimized they are both 26 seconds we should probably use #pragmas to ensure it is optimized Still have NT386 tables, to be removed soon. From jkrell at elego.de Sun Mar 7 04:21:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:21:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032148.A06B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:21:47 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ulong typedef is unused now, remove it From jkrell at elego.de Sun Mar 7 04:24:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:24:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032420.9D4112474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:24:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove all the "not yet" stuff I put in recently: math with overflow checking I still think we might do something like this, though we can probably write it just as well in Modula-3, if not get the compiler to give us the carry flag (certainly m3back can do better) Anyway, we can recover it from here if needed. From jay.krell at cornell.edu Sun Mar 7 04:24:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:24:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032420.9D4112474001@birch.elegosoft.com> References: <20100307032420.9D4112474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:24:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:24:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > remove all the "not yet" stuff I put in recently: math with overflow checking > I still think we might do something like this, though > we can probably write it just as well in Modula-3, > if not get the compiler to give us the carry flag (certainly > m3back can do better) > Anyway, we can recover it from here if needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:26:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032619.2B77B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:26:19 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: again remove set_member and set_singleton: neither backend references them any longer From jkrell at elego.de Sun Mar 7 04:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032706.2E8CD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:27:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove #define of __fastcall, unused From jkrell at elego.de Sun Mar 7 04:28:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:28:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032816.7237A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:28:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put _lowbits, _highbits under #ifdef _WIN32; m3back uses them for insert/extract; they will go away soon anyway From jay.krell at cornell.edu Sun Mar 7 04:20:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:20:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032021.E1DFF2474001@birch.elegosoft.com> References: <20100307032021.E1DFF2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:20:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:20:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c > > Log message: > replace set_range with set_range_new > set_range_new is never significantly slower and sometimes significantly faster, > depending on architecture, compiler, optimization flags > optimization definitely helps this code a lot sometimes, e.g. > old is 9 seconds unoptimized on sparc64, new is 3 seconds > unoptimized they are both 26 seconds > we should probably use #pragmas to ensure it is optimized > > Still have NT386 tables, to be removed soon. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:32:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033246.0A6542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:32:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the old div and mod functions put the current 64bit div and mod under #ifdef _WIN32 gcc backend no longer references any div/mod functions and m3back only does so for 64bit longint (at least for now) From jkrell at elego.de Sun Mar 7 04:33:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:33:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033348.D46452474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:33:48 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove very old 'crash' function that has been sitting here commented out for years From jkrell at elego.de Sun Mar 7 04:35:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:35:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033535.3006B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:35:34 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define WIN32_STATIC From jkrell at elego.de Sun Mar 7 04:36:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033619.C8A202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define INT64_MIN, INT64_MAX, they probably went with the math with overflow checking functions From jkrell at elego.de Sun Mar 7 04:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033651.042102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: oops: the new set_range must not be static From jkrell at elego.de Sun Mar 7 04:49:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:49:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307034944.02C542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:49:43 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove whitespace from ends of lines From jkrell at elego.de Sun Mar 7 04:50:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307035015.D283F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:50:15 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: restore INT64_MIN, INT64_MAX (test code only) From jkrell at elego.de Sun Mar 7 05:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307043751.99BB92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:37:51 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: demonstrate the formula m3back uses for more efficient bit extraction it is x86 specific in that shift counts are treated mod 32 and it doesn't work for extracting zero bits, we should check that we are never asked for that From jkrell at elego.de Sun Mar 7 05:45:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:45:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307044521.881992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:45:21 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: don't allow extracting and sign extending zero bits From jay.krell at cornell.edu Sun Mar 7 05:46:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 04:46:05 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307044521.881992474001@birch.elegosoft.com> References: <20100307044521.881992474001@birch.elegosoft.com> Message-ID: small diff attached/inline Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.113 diff -u -r1.113 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:55:52 -0000 1.113 +++ Stackx86.m3 7 Mar 2010 04:42:39 -0000 @@ -1641,6 +1641,15 @@ really messy to cover all the special cases correctly *) IF sign THEN + + (* The method used here does not work for extracting zero bits. + * Make sure we are not asked to do that. + *) + IF NOT (stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero)) THEN + t.Err("doextract: not able to extract and sign extend zero bits"); + END; + <* ASSERT stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero) *> + find(t, stack0, Force.regset, RegSet { ECX }); find(t, stack1, Force.any); find(t, stack2, Force.anyreg); > Date: Sun, 7 Mar 2010 05:45:21 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 05:45:21 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > don't allow extracting and sign extending zero bits > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 07:38:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307063812.61BC82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:38:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put back assertions, until I verify there are separate runtime checks; put uint32 check and typedef next to each other From jkrell at elego.de Sun Mar 7 07:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064053.7CE822474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:40:53 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: move #define I64 from hand.c to test_hand.c From jkrell at elego.de Sun Mar 7 07:47:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:47:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064702.607B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:47:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the insert/extract64 functions from non-Windows builds From jkrell at elego.de Sun Mar 7 07:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064855.0D38C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:48:54 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix indentation of set_range From jkrell at elego.de Sun Mar 7 07:49:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:49:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064932.6667C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:49:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ~0UL => ~(size_t)0 From jkrell at elego.de Sun Mar 7 08:09:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 8:09:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307070937.AF9B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 08:09:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 Log message: put ASSERT FALSE after every error Also this way I don't have to repeat every condition. From jay.krell at cornell.edu Sun Mar 7 08:10:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 07:10:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307070937.AF9B92474001@birch.elegosoft.com> References: <20100307070937.AF9B92474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 08:09:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 08:09:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 > > Log message: > put ASSERT FALSE after every error > Also this way I don't have to repeat every condition. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 09:31:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 9:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307083125.E71382474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 09:31:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: make procedure find a little more conservative with regard to the 64bit longint changes in particular, don't change the 'set' variable, instead: - in[i] := inreg(t, opA[i].mvar, set); - IF size > 1 THEN - set := set - RegSet{in[i]}; + IF i = 0 THEN + in[i] := inreg(t, opA[i].mvar, set); + ELSE + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); END; (though I was hoping to remove the assumption that size <= 2, I have increased) put procedure pushnew1 and procedure pushnew back together as one procedure, with loops inside it it kind of looks like otherwise might have e.g. saved stuff to two temporary variables instead of one rename procedure maybe_expand_stack to expand_stack it still only expands the stack sometimes, but I think the name is adequate eliminate unnecessary variable 'size' in procedure discard some whitespace/commenting changes From jay.krell at cornell.edu Sun Mar 7 09:38:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 08:38:07 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307083125.E71382474001@birch.elegosoft.com> References: <20100307083125.E71382474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 09:31:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 09:31:25 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > make procedure find a little more conservative > with regard to the 64bit longint changes > in particular, don't change the 'set' variable, > instead: > > - in[i] := inreg(t, opA[i].mvar, set); > - IF size > 1 THEN > - set := set - RegSet{in[i]}; > + IF i = 0 THEN > + in[i] := inreg(t, opA[i].mvar, set); > + ELSE > + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); > END; > > (though I was hoping to remove the assumption that size <= 2, I have increased) > > put procedure pushnew1 and procedure pushnew back together as > one procedure, with loops inside it > it kind of looks like otherwise might have e.g. saved stuff to two temporary variables > instead of one > > rename procedure maybe_expand_stack to expand_stack > it still only expands the stack sometimes, but I think the name is adequate > > eliminate unnecessary variable 'size' in procedure discard > > some whitespace/commenting changes > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 10:15:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:15:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091540.25EEF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:15:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091840.E254B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:40 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091854.484B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 12:11:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 12:11:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307111154.C02122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 12:11:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: correct and increase restrictions on extract parameters n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) if sign_extend, then must be constant and > 1 There is historical code for dealing with non-constant n and sign extension, and it is apparently clever and correct, except it doesn't work for n = 0. If we need this to work better, we could insert a runtime check for n = 0, or use code that handles 0 (see hand.c, at least for now). Word/Long do not expose extract with sign extension. The option is available only to m3back clients, ie. m3front, and it's not hard to imagine that the number of bits it wants is always constant and never 0. From jay.krell at cornell.edu Sun Mar 7 12:16:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 11:16:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307111154.C02122474001@birch.elegosoft.com> References: <20100307111154.C02122474001@birch.elegosoft.com> Message-ID: attached > Date: Sun, 7 Mar 2010 12:11:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 12:11:54 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > correct and increase restrictions on extract parameters > n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) > if sign_extend, then must be constant and > 1 > > There is historical code for dealing with non-constant n and sign extension, > and it is apparently clever and correct, except it doesn't work for n = 0. > If we need this to work better, we could insert a runtime check for n = 0, > or use code that handles 0 (see hand.c, at least for now). > > Word/Long do not expose extract with sign extension. > The option is available only to m3back clients, ie. m3front, > and it's not hard to imagine that the number of bits it wants > is always constant and never 0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307120326.C3A742474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:03:26 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove commented out code regarding bin_use and lib_use (which don't exist) From jkrell at elego.de Sun Mar 7 13:13:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:13:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307121318.8535A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:13:18 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: make -no-m3ship-resolution work in more circumstances, such as when environment variable CM3_INSTALL has forward slashes, on Windows. Note that we now break -no-m3ship-resolution in the unusual case of a Posix user using \ as a "normal" path character. I consider that highly unlikely, however if needed, there are other solutions here. From jay.krell at cornell.edu Sun Mar 7 13:14:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 12:14:08 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307121318.8535A2474001@birch.elegosoft.com> References: <20100307121318.8535A2474001@birch.elegosoft.com> Message-ID: diff attached - Jay > Date: Sun, 7 Mar 2010 13:13:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 13:13:18 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > make -no-m3ship-resolution work in more circumstances, such > as when environment variable CM3_INSTALL has forward slashes, > on Windows. > Note that we now break -no-m3ship-resolution in the unusual > case of a Posix user using \ as a "normal" path character. > I consider that highly unlikely, however if needed, there > are other solutions here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307123914.717A22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:39:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> after ever Err() I thought I had already done this, but I missed a bunch. This way we get a callstack. From jkrell at elego.de Sun Mar 7 13:44:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:44:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307124411.AB5D52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:44:11 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: wordsmithing/comments: in particular, make it completely obvious to any quick observer which code is commented out, by putting * at the start of every line From jkrell at elego.de Sun Mar 7 15:12:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:12:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141218.728F62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! From jkrell at elego.de Sun Mar 7 15:17:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:17:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141745.C5E312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:17:45 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 Log message: further narrow down extract to what m3front uses and we can therefore test => sign_extend requires constant m and constant n (I'm thinking I should see if the coverage stuff works.. and if not fix it..) stack should handle all 32bit cases inline leaving the function calls only for some 64bit cases (for now) something is fishy here for 64bit + sign extension + non constant m/n will resolve shortly (for now I'm leaving 64bit extract + sign extend + non constant m/n) some newlines for readability From jay.krell at cornell.edu Sun Mar 7 15:18:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 14:18:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141745.C5E312474001@birch.elegosoft.com> References: <20100307141745.C5E312474001@birch.elegosoft.com> Message-ID: diff attached.. > Date: Sun, 7 Mar 2010 15:17:45 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:17:45 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 > > Log message: > further narrow down extract to what m3front uses > and we can therefore test > => sign_extend requires constant m and constant n > (I'm thinking I should see if the coverage stuff works.. > and if not fix it..) > > stack should handle all 32bit cases inline > leaving the function calls only for some 64bit cases (for now) > > something is fishy here for 64bit + sign extension + non constant m/n > will resolve shortly > (for now I'm leaving 64bit extract + sign extend + non constant m/n) > > some newlines for readability > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From hosking at cs.purdue.edu Sun Mar 7 17:03:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Mar 2010 11:03:51 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141218.728F62474001@birch.elegosoft.com> References: <20100307141218.728F62474001@birch.elegosoft.com> Message-ID: That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:12:18 > > Modified files: > cm3/m3-sys/m3front/src/builtinOps/: Number.m3 > > Log message: > Fix test p078. > Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it > easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Sun Mar 7 17:08:50 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 7 Mar 2010 17:08:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307160850.E8CB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/07 17:08:50 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Let's just preserve the historical sense of things for easier diffing from prehistory. [Jay, yes I know that you think it is easier to read without the logical negations, but I want to have something that avoids gratuitous changes in the record that make diffing with past versions noisier than necessary.] From jay.krell at cornell.edu Sun Mar 7 23:29:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 22:29:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100307141218.728F62474001@birch.elegosoft.com>, Message-ID: Imagine you were writing a bounds check with INTEGER. Would you write: a, min, max: INTEGER; IF a >= min AND a <= max reasonable IF min <= a AND a <= max reasonable IF NOT a < min AND NOT max < a seems kind of contorted? but ok. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Mar 2010 11:03:51 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 05:28:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308042831.4D0652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:28:31 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more 64bit division tests From jkrell at elego.de Mon Mar 8 05:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044736.39EF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:47:36 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more division tests, in particular of constants that don't fit in 32bits and that are powers of 2 From jkrell at elego.de Mon Mar 8 05:48:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:48:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044802.9DFD22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:48:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: inline 64bit sign extending extracts (constant m/n) actually related to sign extending 64bit right shift it depends on that for the implementation actually related to 64bit division with constants, since the frontend converts some of them to 64bit extract_mn (see test p227) From jay.krell at cornell.edu Mon Mar 8 05:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 04:48:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308044802.9DFD22474001@birch.elegosoft.com> References: <20100308044802.9DFD22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 05:48:02 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 05:48:02 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > inline 64bit sign extending extracts (constant m/n) > actually related to sign extending 64bit right shift > it depends on that for the implementation > actually related to 64bit division with constants, since > the frontend converts some of them to 64bit extract_mn (see test p227) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Mon Mar 8 05:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308045713.865762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:57:13 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove support for 64bit sign extending extract the backend inlines them all now (they always have constant m and n) From jkrell at elego.de Mon Mar 8 06:08:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 6:08:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308050802.414FB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 06:08:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove asserts from insert/extract, runtime checks are already done before this From jkrell at elego.de Mon Mar 8 10:41:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:41:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094115.6FFD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:41:15 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: fix last minute edits From jkrell at elego.de Mon Mar 8 10:45:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:45:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094503.7B0842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:45:03 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: perhaps cleaner to call the '1' functions less and the 'normal' functions more, only calling 'foo1' from 'foo' and nowhere else From jkrell at elego.de Mon Mar 8 13:26:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 13:26:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308122636.83CA12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 13:26:36 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" extract to not use tables and always be inlined for 64bit equivalent C code: UT __stdcall extract(UT x, uint32 offset, uint32 count) { x >>= offset; x &= ~((~(UT)0) << count); return x; } extract32 00000729: 8B4DEC MOV ECX tv.126[_m] 0000072C: 8B5DF4 MOV EBX tv.124[_a32] 0000072F: D3EB SHR EBX 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. 00000733: 8B4DE4 MOV ECX tv.128[_n] 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? 0000073B: D3E6 SHL ESI 0000073D: F7D6 NOT ESI 0000073F: 23DE AND EBX ESI extract64 000008E4: 8B4DD8 MOV ECX tv.134[_m] 000008E7: 8B5DE8 MOV EBX tv.131[_a64] 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 000008ED: 0FADD3 SHRD EBX EDX ECX 000008F0: D3EA SHR EDX 000008F2: F6C120 TEST ECX $32 000008F5: 7400 JE rel8 L.107 000008F7: 8BDA MOV EBX EDX 000008F9: 33D2 XOR EDX EDX set_label L.107 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. 000008FD: 8B4DD0 MOV ECX tv.136[_n] 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) 0000090A: 0FA5F8 SHLD EAX EDI ECX 0000090D: D3E7 SHL EDI 0000090F: F6C120 TEST ECX $32 00000912: 7400 JE rel8 L.108 00000914: 8BC7 MOV EAX EDI 00000916: 33FF XOR EDI EDI set_label L.108 00000918: F7D7 NOT EDI 0000091A: F7D0 NOT EAX 0000091C: 23DF AND EBX EDI 0000091E: 23D0 AND EDX EAX having n or m and n (or just m? I think so.) be constant leads to better code some other small cleanup, like avoiding calling find twice, I don't see why it was that way From jay.krell at cornell.edu Mon Mar 8 13:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 12:30:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308122636.83CA12474001@birch.elegosoft.com> References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308130650.47BA72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:06:50 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a lot of renaming for a lot more readability n => count m => offset consider that have functions insert, insert_n, insert_mn extract, extract_n, extract_mn it gets confusing and then more so, stack0 => stack_offset, stack_count, etc. stop0 => op_offset, op_count, etc. It's even worse there. Functions with so many parameters should use names, not stack offsets. From jay.krell at cornell.edu Mon Mar 8 14:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308130650.47BA72474001@birch.elegosoft.com> References: <20100308130650.47BA72474001@birch.elegosoft.com> Message-ID: diff attached it's a lot of churn but the result is much easier to read - Jay > Date: Mon, 8 Mar 2010 14:06:50 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:06:50 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a lot of renaming for a lot more readability > n => count > m => offset > > consider that have functions > insert, insert_n, insert_mn > extract, extract_n, extract_mn > > it gets confusing > > and then more so, > > stack0 => stack_offset, stack_count, etc. > stop0 => op_offset, op_count, etc. > > It's even worse there. Functions with > so many parameters should use names, not stack offsets. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:18:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:18:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308131806.6019F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:18:06 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little bit of cleanup and dead code removal including: another numbered to named variable sign_extending extract without constant offset/count From jay.krell at cornell.edu Mon Mar 8 14:18:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:18:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308131806.6019F2474001@birch.elegosoft.com> References: <20100308131806.6019F2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 14:18:06 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:18:06 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a little bit of cleanup and dead code removal > including: > another numbered to named variable > sign_extending extract without constant offset/count > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135335.0184A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:53:34 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: It helps to split TestInsert/TestExtract into TestInsert32/TestInsert64/TestExtract32/TestExtract64 because the backend reuses temporary variables and their names end up confusing, if you read the debug output. From jkrell at elego.de Mon Mar 8 14:54:10 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:54:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135410.663152474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:54:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: remove sign_extend, it was always 0 From jkrell at elego.de Mon Mar 8 14:59:26 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:59:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135926.D46412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:59:26 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm32 stdout.pgm64 Log message: update output: from LINUXLIBC6 and AMD64_DARWIN From hosking at cs.purdue.edu Mon Mar 8 16:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 8 Mar 2010 10:29:00 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/08 13:26:36 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > > > Log message: > > "rewrite" extract to not use tables and always be inlined for 64bit > > > > equivalent C code: > > > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > > { > > x >>= offset; > > x &= ~((~(UT)0) << count); > > return x; > > } > > > > extract32 > > 00000729: 8B4DEC MOV ECX tv.126[_m] > > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > > 0000072F: D3EB SHR EBX > > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > > 00000733: 8B4DE4 MOV ECX tv.128[_n] > > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > > 0000073B: D3E6 SHL ESI > > 0000073D: F7D6 NOT ESI > > 0000073F: 23DE AND EBX ESI > > > > extract64 > > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > > 000008ED: 0FADD3 SHRD EBX EDX ECX > > 000008F0: D3EA SHR EDX > > 000008F2: F6C120 TEST ECX $32 > > 000008F5: 7400 JE rel8 L.107 > > 000008F7: 8BDA MOV EBX EDX > > 000008F9: 33D2 XOR EDX EDX > > set_label L.107 > > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > > 0000090A: 0FA5F8 SHLD EAX EDI ECX > > 0000090D: D3E7 SHL EDI > > 0000090F: F6C120 TEST ECX $32 > > 00000912: 7400 JE rel8 L.108 > > 00000914: 8BC7 MOV EAX EDI > > 00000916: 33FF XOR EDI EDI > > set_label L.108 > > 00000918: F7D7 NOT EDI > > 0000091A: F7D0 NOT EAX > > 0000091C: 23DF AND EBX EDI > > 0000091E: 23D0 AND EDX EAX > > > > having n or m and n (or just m? I think so.) be constant leads to better code > > > > some other small cleanup, like avoiding calling find twice, > > I don't see why it was that way > > > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 17:03:48 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308160348.F40EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:03:48 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" insert to not use tables and to inline 64bit operations It is modeled after: T insert(T to, T from, uint32 offset, uint32 count) { T mask = ((~((~(T)0) << count)) << offset); return (to & ~mask) | ((from << offset) & mask); } I spent some time trying to remove the unnecessary instructions. No luck yet. The problem is the codegen wants to preserve offset/count after we are done with them. The usage of the constant "-1" will be optimized later. Constant offset and count should generate much better code. Just constant offset or count, not much different (shift immediate instead of shift by ecx). er, actually the shifts might be significantly optimized. Calculation of the mask ought to be better just for constant count, to be looked at later. It may be profitable to come up with other formulas. These at least are "branch free" (except for the branches within the shifts). The basic general patterns are, which you can see follow the C code closely: insert Word.32 00000226: 8B4DD0 MOV ECX tv.103[_n] 00000229: BEFFFFFFFF MOV ESI $4294967295 0000022E: D3E6 SHL ESI 00000230: F7D6 NOT ESI 00000232: 8BF9 MOV EDI ECX This isn't needed! 00000234: 8B4DD8 MOV ECX tv.101[_m] 00000237: D3E6 SHL ESI 00000239: D3E2 SHL EDX 0000023B: 23D6 AND EDX ESI 0000023D: F7D6 NOT ESI 0000023F: 23DE AND EBX ESI 00000241: 0BDA OR EBX EDX insert Word.64 000004EB: 8B4DB0 MOV ECX tv.117[_n] 000004EE: BBFFFFFFFF MOV EBX $4294967295 000004F3: BEFFFFFFFF MOV ESI $4294967295 000004F8: 0FA5DE SHLD ESI EBX ECX 000004FB: D3E3 SHL EBX 000004FD: F6C120 TEST ECX $32 00000500: 7400 JE rel8 L.75 00000502: 8BF3 MOV ESI EBX 00000504: 33DB XOR EBX EBX set_label L.75 00000506: F7D3 NOT EBX 00000508: F7D6 NOT ESI 0000050A: 8BF9 MOV EDI ECX 0000050C: 8B4DB8 MOV ECX tv.115[_m] 0000050F: 0FA5DE SHLD ESI EBX ECX 00000512: D3E3 SHL EBX 00000514: F6C120 TEST ECX $32 00000517: 7400 JE rel8 L.76 00000519: 8BF3 MOV ESI EBX 0000051B: 33DB XOR EBX EBX set_label L.76 0000051D: 0FA5C2 SHLD EDX EAX ECX 00000520: D3E0 SHL EAX 00000522: F6C120 TEST ECX $32 00000525: 7400 JE rel8 L.77 00000527: 8BD0 MOV EDX EAX 00000529: 33C0 XOR EAX EAX set_label L.77 0000052B: 23C3 AND EAX EBX 0000052D: 23D6 AND EDX ESI 0000052F: F7D3 NOT EBX 00000531: F7D6 NOT ESI declare_temp 4 4 Int.32 F tv.119[T$119] -88 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! 00000536: 8B7DE8 MOV EDI tv.108[_a64] declare_temp 4 4 Int.32 F tv.120[T$120] -92 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 0000053F: 23FB AND EDI EBX 00000541: 23CE AND ECX ESI 00000543: 0BF8 OR EDI EAX 00000545: 0BCA OR ECX EDX free_temp tv.120[T$120] free_temp tv.119[T$119] From jay.krell at cornell.edu Mon Mar 8 17:04:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:04:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , Message-ID: Fair enough. - Jay From: hosking at cs.purdue.edu Date: Mon, 8 Mar 2010 10:29:00 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 8 17:18:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:18:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308160348.F40EB2474001@birch.elegosoft.com> References: <20100308160348.F40EB2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 17:03:48 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 17:03:48 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" insert to not use tables and to inline 64bit operations > > It is modeled after: > > T insert(T to, T from, uint32 offset, uint32 count) > { > T mask = ((~((~(T)0) << count)) << offset); > return (to & ~mask) | ((from << offset) & mask); > } > > I spent some time trying to remove the unnecessary instructions. > No luck yet. The problem is the codegen wants to preserve offset/count > after we are done with them. > > The usage of the constant "-1" will be optimized later. > > Constant offset and count should generate much better code. > Just constant offset or count, not much different (shift immediate instead of shift by ecx). > er, actually the shifts might be significantly optimized. > Calculation of the mask ought to be better just for constant count, to be looked at later. > > It may be profitable to come up with other formulas. > These at least are "branch free" (except for the branches within the shifts). > > The basic general patterns are, which you can see follow the C code closely: > > insert Word.32 > 00000226: 8B4DD0 MOV ECX tv.103[_n] > 00000229: BEFFFFFFFF MOV ESI $4294967295 > 0000022E: D3E6 SHL ESI > 00000230: F7D6 NOT ESI > 00000232: 8BF9 MOV EDI ECX This isn't needed! > 00000234: 8B4DD8 MOV ECX tv.101[_m] > 00000237: D3E6 SHL ESI > 00000239: D3E2 SHL EDX > 0000023B: 23D6 AND EDX ESI > 0000023D: F7D6 NOT ESI > 0000023F: 23DE AND EBX ESI > 00000241: 0BDA OR EBX EDX > > insert Word.64 > 000004EB: 8B4DB0 MOV ECX tv.117[_n] > 000004EE: BBFFFFFFFF MOV EBX $4294967295 > 000004F3: BEFFFFFFFF MOV ESI $4294967295 > 000004F8: 0FA5DE SHLD ESI EBX ECX > 000004FB: D3E3 SHL EBX > 000004FD: F6C120 TEST ECX $32 > 00000500: 7400 JE rel8 L.75 > 00000502: 8BF3 MOV ESI EBX > 00000504: 33DB XOR EBX EBX > set_label L.75 > 00000506: F7D3 NOT EBX > 00000508: F7D6 NOT ESI > 0000050A: 8BF9 MOV EDI ECX > 0000050C: 8B4DB8 MOV ECX tv.115[_m] > 0000050F: 0FA5DE SHLD ESI EBX ECX > 00000512: D3E3 SHL EBX > 00000514: F6C120 TEST ECX $32 > 00000517: 7400 JE rel8 L.76 > 00000519: 8BF3 MOV ESI EBX > 0000051B: 33DB XOR EBX EBX > set_label L.76 > 0000051D: 0FA5C2 SHLD EDX EAX ECX > 00000520: D3E0 SHL EAX > 00000522: F6C120 TEST ECX $32 > 00000525: 7400 JE rel8 L.77 > 00000527: 8BD0 MOV EDX EAX > 00000529: 33C0 XOR EAX EAX > set_label L.77 > 0000052B: 23C3 AND EAX EBX > 0000052D: 23D6 AND EDX ESI > 0000052F: F7D3 NOT EBX > 00000531: F7D6 NOT ESI > declare_temp 4 4 Int.32 F tv.119[T$119] -88 > 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! > 00000536: 8B7DE8 MOV EDI tv.108[_a64] > declare_temp 4 4 Int.32 F tv.120[T$120] -92 > 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! > 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 > 0000053F: 23FB AND EDI EBX > 00000541: 23CE AND ECX ESI > 00000543: 0BF8 OR EDI EAX > 00000545: 0BCA OR ECX EDX > free_temp tv.120[T$120] > free_temp tv.119[T$119] > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 17:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308162149.D4E4A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:21:49 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Removed files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove no longer used 64bit insert/extract functions remove no longer used _lowbits/_highbits tables that NT386 used to use for 32bit insert/extract test code has nothing left to test now (there is still stuff in hand.c, but test_hand.c didn't test it) From jkrell at elego.de Tue Mar 9 17:09:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:09:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309160900.CF5352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:09:00 Modified files: cm3/scripts/python/: pylib.py Log message: fix newlines From jkrell at elego.de Tue Mar 9 17:10:08 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:10:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309161008.3D8192474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:10:08 Modified files: cm3/scripts/python/: pylib.py Log message: code to detect Visual C++ version from its banner, so we can build an .msi for every or almost every one (I'm missing some right now), preprocessing the string _MSC_VER is another good way From jkrell at elego.de Tue Mar 9 17:29:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:29:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309162937.904482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:29:37 Modified files: cm3/scripts/python/: pylib.py Log message: don't put cm3cg in NT386 packages From jkrell at elego.de Tue Mar 9 17:41:05 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:41:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309164105.1EB322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:41:05 Modified files: cm3/scripts/python/: pylib.py Log message: tag NT386 distribution file names with Visual C++ version e.g. cm3-std-NT386-d5.8.2-VC90.tgz, m3-std-NT386-d5.8.2-VC80.msi, etc. From jkrell at elego.de Tue Mar 9 17:56:19 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:56:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309165619.700AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:56:19 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: COPY from head: PPC64_DARWIN support remove PIC building some SPARC bootstraps don't put cm3cg in NT386 packages stamp NT386 package files with Visual C++ version remove leading underscore from ConvertFromCygwinPath, ConvertToCygwinPath so they are public remove 'base' and 'core' package sets some Interix stuff (which I think isn't needed anywhere) support for editing in -debug switch From jkrell at elego.de Wed Mar 10 09:43:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 9:43:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310084320.99E8B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 09:43:20 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86Rep.i3 Stackx86.i3 Stackx86.m3 Log message: selective 'INTEGER' => 'CARDINAL' From jkrell at elego.de Wed Mar 10 11:31:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:31:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103136.BDE3F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) From jkrell at elego.de Wed Mar 10 11:32:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:32:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103247.98D402474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:32:47 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Wed Mar 10 11:34:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103405.A42882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:05 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: when checking for case insensitive inequality, first check for case sensitive equality From jkrell at elego.de Wed Mar 10 11:34:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103456.7D46B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:56 Modified files: cm3/m3-libs/sysutils/src/: PathReprCommon.m3 Log message: fix typos in comments From jkrell at elego.de Wed Mar 10 11:37:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:37:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103756.9D3BB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:37:56 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: if asked to replace something with itself, just return the original without any searching From jkrell at elego.de Wed Mar 10 11:41:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:41:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104139.B6A712474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:41:39 Modified files: cm3/m3-libs/sysutils/src/: EnvUtils.m3 FSUtils.i3 FSUtils.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 MsgX.m3 OSSpecials.i3 PathRepr.i3 ProcessEnv.i3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 m3makefile cm3/m3-libs/sysutils/src/POSIX/: OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 m3makefile cm3/m3-libs/sysutils/src/WIN32/: OSSpecialsWin32.m3 PathReprWin32.m3 SystemWin32.m3 m3makefile cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 m3makefile cm3/m3-libs/sysutils/src/pm3/: TextUtils.m3 m3makefile Log message: remove $Id$, it adds noise when comparing branches I'll take the liberty of assuming $Id$ is not part of the license text that is usually adjacent to. From jkrell at elego.de Wed Mar 10 11:45:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:45:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104544.7AF4F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:45:44 Modified files: cm3/m3-libs/sysutils/src/: Confirmation.i3 Confirmation.m3 ConnectRdWr.m3 EnvUtils.i3 EnvUtils.m3 FSUtils.m3 FSUtilsUnsafe.i3 FastLex.i3 FingerprintFmt.i3 FingerprintFmt.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 OSSpecials.i3 PathReprCommon.m3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/sysutils/src/pm3/: RdExtras.m3 TextUtils.m3 Log message: remove whitespace at ends of lines From jkrell at elego.de Wed Mar 10 15:18:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:18:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310141843.A73942474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:18:43 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: compare operandPart when comparing stackp really something larger is bothering me, looking into the assertion failure when I try to remove unnecessary instructions from insert/extract We get into a situation where part of a value is in one of the correct registers, but hi is in low or vice versa, and in moving things around, we do the wrong thing. Like if we want return value in EDX:EAX and the value is currently in EAX:ECX, we do like: XCHG EAX,ECX ; put the low part in EAX where it belongs MOV EDX, EAX ; wrong, should be MOV EDX, ECX, or reverse ; the two instructions I don't know that there is a problem here in practise or not, since I've only seen it so far looking at uncommited changes. From jkrell at elego.de Wed Mar 10 15:22:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:22:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142256.0812A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:22:56 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: store operandPart := -1 whenever we store stackp := -1 From jkrell at elego.de Wed Mar 10 15:24:00 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:24:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142400.40C1A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:24:00 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: finish the change that follows errors with assertion failures From jkrell at elego.de Wed Mar 10 15:40:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:40:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144047.BD9A02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:40:47 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: just add comments From jkrell at elego.de Wed Mar 10 15:41:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:41:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144132.E0E692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:41:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: slight simplification, perhaps, in procedure swap From jkrell at elego.de Wed Mar 10 15:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145132.9770E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:51:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: safe keeping: this generates insert/extract better but either causes or reveals a register allocation problem, followed by an assertion failure; the register allocation problem can be seen here: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG EAX ECX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] 64bit return values are EDX:EAX. This has, by chance, the value in EAX:ECX, and then messes up converting it to EDX:EAX. From jkrell at elego.de Wed Mar 10 15:52:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:52:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145251.900B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:52:51 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: go back to version 1.131 From jkrell at elego.de Wed Mar 10 16:12:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:12:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310151231.8F9412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:12:31 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Now that I finally think enough, a nice little fix to the register allocator to handle when a multi register operand is partly in the right registers, but with the part mixed up. It yields us at the end of Long__Insert this: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG ECX EAX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] again it'd be nice if we had ECX:EAX in the first place instead of EAX:ECX, or even EDX:EAX. And then, a roundabout but understandable way to eliminate the unnecessary stores in insert/extract. The extra checking under -debug forces to rearrange the virtual stack and discard(), rather than just say dealloc_reg. If "location" could be "nowhere" that might help, but we have to chose between immediate, register, float stack, memory_variable. And then Modula-3 WITH either because of how it behaves or because of my confusion -- I think actually for reasons related to "safety", we have to "reevaluate" a few times -- each time we discard anything from the stack. Leading to a bit extra code but it is fairly clear. From jkrell at elego.de Wed Mar 10 16:49:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:49:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310154926.63AFE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:49:26 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: two small improvements 1) If we were trying to put 64bit value in EDX:EAX such as we assume is for a return value, and either part of the value wasn't in place, we would do work for both parts. The result was typically throwing in "xchg edx,edx" which does nothing. Now we only work on whatever part isn't where it should be. This could be seen e.g. in Long__Plus. Caught by adding assert to # from in swapreg. 2) If we are allocating a 64bit value and EAX is chosen for one of the registers, force it to be the low part. This saves an instruction in Long__Insert and easy to imagine elsewhere. There's really no downside. Unless maybe you are about to shift or rotate by a constant of 32 or more, or extract/insert with an offset of 32 or more (and even then, I think we can address that) If the high part is already in a register (i.e. EAX), then leave it there. I don't think this can happen since, like, we don't have a notion of "splitting" or "merging" allocation. e.g., ideally: stuff like: a := 0L or a := -1L would fit in one register or a := 0L; a := Long.Or(a, VAL(integer, LONGINT)) would be an immediate plus one register, instead of two registers From hosking at cs.purdue.edu Wed Mar 10 16:53:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 10:53:16 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100310103136.BDE3F2474001@birch.elegosoft.com> References: <20100310103136.BDE3F2474001@birch.elegosoft.com> Message-ID: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Mar 10 17:00:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 16:00:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Mar 2010 10:53:16 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 10 17:08:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 11:08:01 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: <49CA2A26-57BD-462F-97A6-A86B21107D50@cs.purdue.edu> OK. On 10 Mar 2010, at 11:00, Jay K wrote: > I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. > I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). > > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 10:53:16 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I thought we decided these hacks were not necessary moving forward. > If you want to build CM3 you need an up to date compiler... etc. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 10 Mar 2010, at 11:31, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Mar 10 18:04:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170405.2E11D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:04 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: replace e.g.: 00000022: B8 FF FF FF FF mov eax,0FFFFFFFFh 00000027: BA FF FF FF FF mov edx,0FFFFFFFFh with: 00000020: 83 C8 FF or eax,0FFFFFFFFh 00000023: 83 CA FF or edx,0FFFFFFFFh (mov reg, -1 with or reg, -1 -- smaller encoding, same meaning; both 32bit and 64bit operands) notice the code is a bit wierd, source type vs. dest type, and the number 4 is too creeping (this code should target AMD64_NT eventually) From jkrell at elego.de Wed Mar 10 18:04:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170431.684F72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:31 Modified files: cm3/m3-sys/m3back/src/: TWordN.i3 Log message: fix whitespace From jkrell at elego.de Wed Mar 10 21:52:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205230.445EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:30 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Handle when both registers are allocated to an operand, but in the wrong parts. e.g. we have EAX:EDX but want EDX:EAX. Not actually tested, nor an example seen, but I was thinking about it and it seems clear the previous code would do two swaps, leaving things incorrect. From jkrell at elego.de Wed Mar 10 21:52:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205254.4080C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: fix comment From jkrell at elego.de Wed Mar 10 21:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205625.B33062474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:56:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repition From jkrell at elego.de Wed Mar 10 21:57:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:57:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205733.45C8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:57:33 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repitition, should be equivalent From jkrell at elego.de Wed Mar 10 21:58:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:58:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205844.40A142474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:58:44 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: should be equivalent From jay.krell at cornell.edu Wed Mar 10 23:27:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 22:27:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? You know, that'd be a great hint to: - definitely definitely definitely definitely inline - if we know this thing existed, we could use it instead of a .c file. - along with the function's name for the invocations that aren't the function? Why provide the function anyway? In case someone takes the address? - Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> > <1.txt> > From hosking at cs.purdue.edu Thu Mar 11 01:57:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 19:57:17 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Yes, someone can pass the function as a parameter. I don't understand the rest of what you are saying. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 17:27, Jay K wrote: > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >> <1.txt> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 11 02:30:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 01:30:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. Granted at least two things: Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. And I'm inlined to just always inline anyway. (I still don't like the term "Long" here. It doesn't convey unsigned.) - Jay ________________________________ > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 19:57:17 -0500 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > > > Yes, someone can pass the function as a parameter. > > I don't understand the rest of what you are saying. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 10 Mar 2010, at 17:27, Jay K wrote: > > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x>>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > > <1.txt> > > From hosking at cs.purdue.edu Thu Mar 11 03:01:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 21:01:54 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? On 10 Mar 2010, at 20:30, Jay K wrote: > > If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. > > > That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. > > > That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. > > Granted at least two things: > Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. > And I'm inlined to just always inline anyway. > > > (I still don't like the term "Long" here. It doesn't convey unsigned.) > > > - Jay > > > > ________________________________ >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Wed, 10 Mar 2010 19:57:17 -0500 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> >> Yes, someone can pass the function as a parameter. >> >> I don't understand the rest of what you are saying. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 10 Mar 2010, at 17:27, Jay K wrote: >> >> >> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >> You know, that'd be a great hint to: >> >> - definitely definitely definitely definitely inline >> - if we know this thing existed, we could use it instead of a .c file. >> - along with the function's name for the invocations that aren't the function? >> >> >> Why provide the function anyway? In case someone takes the address? >> >> >> >> - Jay >> >> >> ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> >> <1.txt> >> >> From jay.krell at cornell.edu Thu Mar 11 05:10:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 04:10:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, ,,, , , , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu>, , <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> Message-ID: Long.LeftShift is not a great example. Sorry. Long.Shift, Long.Rotate, Long.Times, LongDivide. Those are or "could be" large. Currently the later three all call functions and are therefore short. Integer.Multiple, Divide, Remainder, similarly uncertain. They call functions, the functions aren't short. I was also thinking, some of these functions, esp. 64bit shift/rotate could be shorter as loops. But I think not worthwhile. To be clear, even though "parse.c" "never" generates function calls (except for set operations), the gcc backend itself often does. The functions are in libgcc. You know..I find it hard to decide about compiler generated function calls. Definitely for size optimization they can be a win. But I just somehow vaguely don't like them. In many cases, the decision is not difficult. set_singleton and set_member are good examples. They could be inlined and be very small. But Shift, Rotate, Multiply, Divide, it gets less clear. But no matter how large an inline form, I think when interface word/long maps directly to these operations, they should be inlined. And then if there are places that don't inline, they should call the "instantiations" in interface word/long. And then, furthermore, we should consider an interface for "Integer.Divide/Multiple/Remainder"? A place to park the possibly large code? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 21:01:54 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? > > On 10 Mar 2010, at 20:30, Jay K wrote: > >> >> If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. >> >> >> That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. >> >> >> That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. >> >> Granted at least two things: >> Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. >> And I'm inlined to just always inline anyway. >> >> >> (I still don't like the term "Long" here. It doesn't convey unsigned.) >> >> >> - Jay >> >> >> >> ________________________________ >>> Subject: Re: [M3commit] CVS Update: cm3 >>> From: hosking at cs.purdue.edu >>> Date: Wed, 10 Mar 2010 19:57:17 -0500 >>> CC: m3commit at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> >>> >>> Yes, someone can pass the function as a parameter. >>> >>> I don't understand the rest of what you are saying. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 10 Mar 2010, at 17:27, Jay K wrote: >>> >>> >>> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >>> You know, that'd be a great hint to: >>> >>> - definitely definitely definitely definitely inline >>> - if we know this thing existed, we could use it instead of a .c file. >>> - along with the function's name for the invocations that aren't the function? >>> >>> >>> Why provide the function anyway? In case someone takes the address? >>> >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 16:04:45 +0000 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> >>> >>> >>> >>> Fair enough. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 10:29:00 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >>> >>> >>> >>> On 8 Mar 2010, at 07:30, Jay K wrote: >>> >>> >>> >>> diff attached >>> >>> >>> If folks really want to use tables or function calls here, let me know. >>> >>> >>> The data was historically problematic, though we worked out the problems. >>> - It was initialized at runtime which has a race condition, fixed years ago. >>> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >>> >>> The data is still used by Word.Insert and Long.Insert is still a function, but those >>> are my next targets. >>> >>> >>> This is a case where the user does write a function call. Word.Extract or Long.Extract. >>> (So the function should have been called Long__Extract.) >>> >>> >>> - Jay >>> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >>> <1.txt> >>> >>> > From hosking at elego.de Thu Mar 11 06:24:29 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:24:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311052429.3EFD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:24:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Use BIT_FIELD_REF for extract_mn. From hosking at elego.de Thu Mar 11 06:36:35 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:36:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311053636.074602474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:36:35 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: A little easier to read. From hosking at elego.de Thu Mar 11 06:40:22 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054022.EDCE42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:40:22 Modified files: cm3/m3-sys/m3front/src/builtinWord/: Insert.mg Log message: Make use of insert_n and insert_mn. This allows simplified range checking for constant m/n. From hosking at elego.de Thu Mar 11 06:42:06 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:42:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054206.B81732474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:42:06 Modified files: cm3/m3-sys/m3middle/src/: M3CG.m3 M3CG_BinWr.m3 M3CG_Check.m3 M3CG_Ops.i3 M3CG_Wr.m3 cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Make arguments to insert_mn insert_n extract_mn extract_n CARDINAL. From jkrell at elego.de Thu Mar 11 16:29:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 11 Mar 2010 16:29:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311152914.4E6AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/11 16:29:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: stop outputing lines that end in just \r (unless caller actually gave us such a thing, which they don't) so I can stop dismissing this very annoying messagebox that also pauses to beep: --------------------------- Microsoft Developer Studio --------------------------- Lines ending with only a carriage return have been detected. These will be modified to include a line feed. --------------------------- OK --------------------------- This was occuring every time I open foo.molog, which is produced by cm3 -debug which I use heavily these days. related, most uses of Target.EOL should be Wr.EOL but that isn't changed here. From rcoleburn at elego.de Fri Mar 12 00:55:52 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 0:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311235552.F0BC62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 00:55:52 Modified files: cm3/scripts/install/windows/: cm3CommandShell.CMD Log message: Add features to look for root of cm3 installation in location of currently running CMD script, then in folders on PATH environment variable, before defaulting to "%SystemDrive%\cm3". Of course the "Root path" argument can still be used to force a specific location.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 01:26:19 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 1:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312002619.5E20F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 01:26:19 Modified files: cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd Log message: Add feature to search PATH env var as a last resort when trying to locate the root of the cm3 installation.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 04:27:46 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 4:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312032746.A46BC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 04:27:46 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Implement quick-fix for problem documented in Trac ticket #1082. The quick-fix is to change the default behavior on Windows such that CM3IDE does not terminate when the browser terminates. I've commented this quick-fix patch in the source code to make it easy to remove if/when we come up with a better solution. Note that if you already have a CM3_IDE.cfg file, it will need to be edited manually for the "start_browser" function, or you can just delete it and CM3IDE will recreate it using the new defaults the next time it runs. This quick-fix patch has no effect on non-Windows systems.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 07:03:44 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 7:03:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312060344.897122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 07:03:44 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Repair bug introduced with quick-fix patch.--R.Coleburn From jkrell at elego.de Fri Mar 12 12:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110412.6C4812474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:04:12 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Stackx86.m3 Log message: insert/extract offset/count INTEGER => CARDINAL, mostly From jkrell at elego.de Fri Mar 12 12:07:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:07:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110736.D5C882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:07:36 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 M3CG_Wr.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:09:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:09:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110928.3CD8D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:09:28 Modified files: cm3/m3-sys/m3front/src/misc/: WebInfo.m3 cm3/m3-sys/m3front/src/values/: Module.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111400.E06592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:00 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Utils.m3 WebFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111458.1D8A92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:58 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111643.5CD652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:16:43 Modified files: cm3/m3-sys/m3linker/src/: MxGen.m3 MxOut.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:19:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:19:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111925.4EA6A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:19:25 Modified files: cm3/m3-sys/m3loader/src/WIN32/: M3LoaderRd.m3 Log message: account for file size now being LONGINT and cast (VAL) to INTEGER From jkrell at elego.de Fri Mar 12 12:26:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112634.6324D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:34 Modified files: cm3/m3-sys/m3loader/src/: Main.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:26:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112658.E9A252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:58 Modified files: cm3/m3-sys/m3tests/src/c1/c130/: OWr.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113017.A525D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:30:17 Modified files: cm3/m3-sys/m3objfile/src/: MasmObjFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113428.E15362474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:34:28 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:36:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:36:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113600.D3D352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:36:00 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:38:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113851.7CAB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:38:51 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 M3Build.m3 Utils.i3 Utils.m3 Log message: CopyText => Copy just copy files directly no end of line conversion From jkrell at elego.de Fri Mar 12 12:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114010.08CE02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:40:09 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Log message: remove text_file: BOOLEAN parameter from PROCEDURE PullForBootstrap From jkrell at elego.de Fri Mar 12 12:42:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:42:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114214.614572474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:42:14 Modified files: cm3/m3-sys/m3middle/src/: M3File.i3 M3File.m3 Log message: remove PROCEDURE CopyText that does newline conversion From jkrell at elego.de Fri Mar 12 12:43:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:43:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114355.854482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:43:55 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: remove Target.EOL From jkrell at elego.de Fri Mar 12 12:44:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:44:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114443.5D53C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:44:43 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add feature so cm3 -Ddebug passes -debug down to the test cases -- they'll never pass that way, but extra information is generated that might be useful From jkrell at elego.de Fri Mar 12 12:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114610.A20E42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:46:10 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: remove commented code for 32bit LONGINT that catered to older m3back From rcoleburn at elego.de Sat Mar 13 02:11:24 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 2:11:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313011125.34CF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 02:11:24 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn From jay.krell at cornell.edu Sat Mar 13 05:47:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 04:47:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313011125.34CF12474001@birch.elegosoft.com> References: <20100313011125.34CF12474001@birch.elegosoft.com> Message-ID: This change is suspicious. I think it leaks. Please see http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/FSWin32.m3?rev=1.7;content-type=text%2Fplain for the pattern that is usually used. Granted, given the conservativeness of the collector -- it finds stuff in registers and the stack without a need for metadata telling it where the points are, and the fact that we no longer have VM-synchronization, I don't understand the need for the usual pattern. Maybe because it is willing to move stuff? Therefore a non-traced copy is made for C that won't ever move? - Jay > Date: Sat, 13 Mar 2010 02:11:24 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 10/03/13 02:11:24 > > Modified files: > cm3/examples/calling-c-win32/src/: OK.m3 > > Log message: > M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at elego.de Sat Mar 13 06:57:59 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 6:57:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313055759.BFEA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 06:57:59 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: Improve this example code by following the prescribed pattern of freeing the shared storage after it is no longer needed.--R.Coleburn From jkrell at elego.de Sat Mar 13 11:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 11:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313100917.133702474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 11:09:17 Added files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 m3makefile Log message: This program endeavors to exercise every sort of integer, float, address comparison, and some set compares, in order to support cleanup and improvement of comparison in m3back. If this isn't fleshed out further, it really belongs in the "c for code" test section. From jkrell at elego.de Sat Mar 13 13:12:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:12:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313121234.2D2122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:12:34 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add the various no overlap and minimal overlap cases that is: no_overlap_less: [0..1] compared to [2..3] no overlap greater: [2..3] compared to [0..1] min overlap less: [0..1] compared to [1..2] min overlap greater: [1..2] compared to [0..1] I have all these optimized for <, >, <=, >= where possible. Not yet = and #. Only for integer and longint, subranges, not yet for enums, not tested for constants. From jkrell at elego.de Sat Mar 13 13:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313122525.A06652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add enum cases From jkrell at elego.de Sat Mar 13 13:32:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123208.5933B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:08 Added files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 m3makefile Log message: a seperate test from p232: This program endeavors to exercise comparisons for subranges and enums that don't overlap or overlap only at the edge. This should probably be in the "c for code" section. What is being tested is that many of these functions return just a constant TRUE or FALSE. From jkrell at elego.de Sat Mar 13 13:32:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123236.BC2BE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:36 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: remove (most of) what was moved to p233 From jkrell at elego.de Sat Mar 13 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313131650.95B082474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:16:50 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add comparisons of CARDINAL to -1 and -2 It looks like I have this all working, except for: <*UNUSED*>PROCEDURE AddressLT0(a:ADDRESS):BOOLEAN=BEGIN RETURN a= NIL because min/max of address is 0/-1, instead 0/2^^32 or 2^^64 perhaps the signedness of address isn't so well defined and this should be left alone anyway. From jkrell at elego.de Sat Mar 13 14:36:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:36:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313133632.5FD172474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:36:32 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add the unusual case of single element subranges (two variables of such type are always equal, etc. (never not equal, always less-or-equal, always greater-or-equal, never less, never greater), and add comments From jkrell at elego.de Sat Mar 13 14:45:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:45:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313134559.5F7DC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:45:59 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: Fairly simple analysis to optimize comparison of subranges that either don't overlap at all, or only "on the edge" ("on the edge" means the max of one is equal to the min of the other or vice versa) I don't presume that this really helps much real world code, but it is pretty simple so shouldn't hurt. Probably it is rare to mix unequal subranges, let alone non-overlapping or barely overlapping, as well probably rare to compare subranges to constants outside the subrange (or again, "on the edge") This handles, integers, longints, enums, constants, but addresses don't work e.g. address < NIL should perhaps always be false. It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? I was surprised to see that they are separate. It also seemed odd to have to call ConstValue before GetBounds. Backends are not directly given the information for them to do this work, though more advanced analysis might regain the information. subranges and enums just end up as generally unbounded int32, etc. (backends do see range checks and can remember what they imply but I believe parameters are not range checked upon receipt, for example) see test case p233 (though it should probably move to the "c for code" section, since running it doesn't do anything, one reads the code and notices that many of the functions are optimized to just return a constant true or false) This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) compares in m3back, which has a pretty non-optimal implementation. From jay.krell at cornell.edu Sat Mar 13 14:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 13:47:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313134559.5F7DC2474001@birch.elegosoft.com> References: <20100313134559.5F7DC2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 14:45:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 14:45:59 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 > > Log message: > Fairly simple analysis to optimize comparison of subranges > that either don't overlap at all, or only "on the edge" > ("on the edge" means the max of one is equal to the min of the other > or vice versa) > > I don't presume that this really helps much real world code, but > it is pretty simple so shouldn't hurt. > Probably it is rare to mix unequal subranges, let alone non-overlapping > or barely overlapping, as well probably rare to compare subranges to > constants outside the subrange (or again, "on the edge") > > This handles, integers, longints, enums, constants, but addresses don't work > e.g. address < NIL should perhaps always be false. > > It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? > I was surprised to see that they are separate. > > It also seemed odd to have to call ConstValue before GetBounds. > > Backends are not directly given the information for them to do this work, though > more advanced analysis might regain the information. > subranges and enums just end up as generally unbounded int32, etc. > (backends do see range checks and can remember what they imply but > I believe parameters are not range checked upon receipt, for example) > > see test case p233 (though it should probably move to the "c for code" section, > since running it doesn't do anything, one reads the code and notices that > many of the functions are optimized to just return a constant true or false) > > This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) > compares in m3back, which has a pretty non-optimal implementation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 15:16:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:16:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313141602.EC5932474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:16:02 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: more test cases, some succeed (at being optimized), some do not. ORD(enum) vs. negative; these work ABS vs. negative; these work ABS vs. 0; these work -ABS vs. cardinal; the only optimizable case is neg_abs_vs_cardinal_GT and it doesn't work -ABS vs. 0; ditto -ABS vs. 1; many optimizable cases, none work ABS has a min of 0 negate of abs should have a max of 0 but is considered unbounded it looks like bounds do not propagate always as they could From jkrell at elego.de Sat Mar 13 15:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313142730.87A5D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:27:30 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: use interface Word, Long to get unsigned operations (I think they should have EQ/NE, instead of teahing people that they are the same as the signed operations..) From jkrell at elego.de Sat Mar 13 15:40:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:40:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313144021.E917A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:40:21 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove some uninteresting cases From jkrell at elego.de Sat Mar 13 15:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313145540.F15B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:55:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp is not reachable (and this isn't related to generalizations in m3middle/m3cg either; it is about a generalization m3back makes mapping a parameter to a larger set and then optimizing the newer values, none of which can ever occur) From jay.krell at cornell.edu Sat Mar 13 15:57:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 14:57:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313145540.F15B72474001@birch.elegosoft.com> References: <20100313145540.F15B72474001@birch.elegosoft.com> Message-ID: small diff attached, with whitespace ignored (as an IF was removed) more coming in this area soon.. > Date: Sat, 13 Mar 2010 15:55:40 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 15:55:40 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp > is not reachable (and this isn't related to generalizations > in m3middle/m3cg either; it is about a generalization m3back > makes mapping a parameter to a larger set and then optimizing > the newer values, none of which can ever occur) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 19:11:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 19:11:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313181114.B14E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 19:11:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 Log message: improve all integer compares, some/all set compares not yet: float compares old pattern: cmp setcc byte in memory xor reg,reg (any register, I believe) mov reg, memory new patterns, depending on comparison/types: xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} cmp setcc reg or cmp possibly with operands reversed sbb reg, reg neg reg or cmp possibly with operands reversed sbb reg, reg inc reg There is a little extra pressure on eax,ebx,ecx,edx, but we save an instruction and we avoid use of an in-memory temporary. The instruction could have been saved by using movzx as the manuals recommend anyway, instead of xor+mov. The sequences are used are based on optimized C. Basic problem here is setcc which only sets a byte but we generally want 32bit values. Possibly more to do here. The main difficulty developing this change was that I didn't initially restrict to RegistersForByteOperations. Small test cases worked ok but cases with more register pressure did not. see test p232 for a test that currently exercises some of this. From jay.krell at cornell.edu Sat Mar 13 19:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 18:12:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313181114.B14E22474001@birch.elegosoft.com> References: <20100313181114.B14E22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 19:11:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 19:11:14 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 > > Log message: > improve all integer compares, some/all set compares > not yet: float compares > > old pattern: > cmp > setcc byte in memory > xor reg,reg (any register, I believe) > mov reg, memory > > new patterns, depending on comparison/types: > xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} > cmp > setcc reg > > or > cmp possibly with operands reversed > sbb reg, reg > neg reg > > or > cmp possibly with operands reversed > sbb reg, reg > inc reg > > There is a little extra pressure on eax,ebx,ecx,edx, but > we save an instruction and we avoid use of an in-memory temporary. > The instruction could have been saved by using movzx as the manuals > recommend anyway, instead of xor+mov. > > The sequences are used are based on optimized C. > > Basic problem here is setcc which only sets a byte > but we generally want 32bit values. > > Possibly more to do here. > > The main difficulty developing this change was > that I didn't initially restrict to RegistersForByteOperations. > Small test cases worked ok but cases with more register pressure did not. > see test p232 for a test that currently exercises some of this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 14 06:29:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 6:29:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314052940.11B272474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 06:29:39 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: go back a version the codegen optimization is ok, but I confused "semantically const" with "opportunistically const" e.g. the following is not legal C: const int a = 1; /* ok */ const int b = a + 1; /* not ok */ int c[a]; /* not ok */ int F() { return 1; } /* ok */ int d = F(); /* not ok */ int e[F()]; /* not ok */ (I'm assuming c89 or such, not c9x.) compiler could optimize: int F1() { return 1; } int F2() { return F() + F1(); } /* => return 2 */ but that occurs "differently". From jkrell at elego.de Sun Mar 14 07:31:23 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 7:31:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314063123.8DFA52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 07:31:23 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: start removing cases that don't work and annotating function names with their expected constant value From jkrell at elego.de Sun Mar 14 11:38:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 11:38:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314103811.E03C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 11:38:11 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove unused import word/long From jkrell at elego.de Sun Mar 14 12:42:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 12:42:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314114239.6B9612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 12:42:39 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove more uninteresting cases, label all cases with expected value; a properly modified cm3 should issue a warning for each procedure From jkrell at elego.de Sun Mar 14 13:35:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 13:35:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314123552.C26EA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 13:35:52 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: call every function and verify they return the right value (which wasn't really ever the point, they always compiled correctly, just inefficiently From jkrell at elego.de Sun Mar 14 14:00:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 14:00:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314130032.4838D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 14:00:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: remove three dead lines left over from when 64bit shifts weren't inlined From jkrell at elego.de Sun Mar 14 16:42:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 16:42:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314154240.673312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 16:42:40 Added files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: initial copy of Atomic.mg, this version won't have all the switch statements From jkrell at elego.de Sun Mar 14 17:02:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:02:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314160230.D13612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:02:30 Modified files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg atomic.tmpl m3makefile Log message: provide a version without a bunch of code from switch statements, esp. for platforms that only have sequential memory models (note that x86 with lfense/sfence/mfence/whatever can do better) From jkrell at elego.de Sun Mar 14 17:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314161830.4E70C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:18:30 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "t" is usually for "type", spell it out (sometimes it is for text) From jkrell at elego.de Sun Mar 14 17:21:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:21:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314162107.9E4042474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:21:04 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'z' is apparently for "type_that_is_a_multiple_of_32bits" spell it out too; maybe a shorter name can be found but I don't think 'z' is it. From jay.krell at cornell.edu Sun Mar 14 17:35:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 16:35:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314162107.9E4042474001@birch.elegosoft.com> References: <20100314162107.9E4042474001@birch.elegosoft.com> Message-ID: Maybe "z" is for "zero extended"? - Jay > Date: Sun, 14 Mar 2010 17:21:04 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 17:21:04 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > 'z' is apparently for "type_that_is_a_multiple_of_32bits" > spell it out too; maybe a shorter name can be found > but I don't think 'z' is it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:23:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:23:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314172342.E94E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:23:42 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: flesh out all the atomic operations, including 8, 16, and 64 bit operations There's some improvement to be had here still. Mainly that we overuse interlocked compare exchange loops. Some operations don't need that, e.g. add, sub, xor. Sometimes even "or" and "and" don't need them either, but we aren't likely to have sufficient context to discover that. In particular, if caller throws out the returned old value, then a direct "lock or" or "lock and" instruction can be used, instead of an interlocked compare exchange. Compare the code to these two functions: char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is just two instructions including the ret. The first contains a loop. Also we might be able to get the zero flag more efficiently for some cases, e.g. the non-64 bit cases. We can xor a register up front, sete it, and mov into eax, instead of going through memory (same number of instructions probably, and increased register pressure). Also register allocater (procedure find) should get an explicit flag to force the ecx:ebx allocation (and edx:eax). We should also try inlined tests, as opposed to interface atomic, and verify we don't unnecessarily enregister the atomic variable's address. That is needed in testing so far since I've just been looking at m3core. (ie: more testing, not just looking at m3core) We should also perhaps implement looser load/store where we only have a barrier on one side instead of both. Presently every atomic load/store is both preceded and followed by a serializing xchg. We should also consider if the barrier variable should be one widely shared global instead of everyone having to waste 4 bytes of stack for it. Note that AtomicLongint__Swap doesn't return the right value currently. Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? Kind of like the funny thing AtomicLongint__Swap does? (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary value for the first try: 0). That is to say, AtomicLongint__Load/Store are not presently atomic! No other correctness problems known. From jay.krell at cornell.edu Sun Mar 14 18:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314172342.E94E22474001@birch.elegosoft.com> References: <20100314172342.E94E22474001@birch.elegosoft.com> Message-ID: > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Sun Mar 14 18:31:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:31:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314172342.E94E22474001@birch.elegosoft.com>, Message-ID: searched the web: http://niallryan.com/node/137 shows 64 bit atomic read/write on x86. Including using floating point to do it..is it right? I'm inclined to implement the non-fp method. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:41:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:41:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174108.9D8772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:41:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Load per http://niallryan.com/node/137 some cleanup AtomicLongint__Store not right yet From jkrell at elego.de Sun Mar 14 18:42:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:42:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174227.AC1C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:42:27 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "type_that_is_a_multiple_of_32bits" => "type_multiple_of_32" It is a bit shorter. We'll see how it goes. From jkrell at elego.de Sun Mar 14 19:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181119.4468E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:11:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Store to be atomic see http://niallryan.com/node/137 I use the lock cmpxhg8b method, not the float method. Note that all the AtomicLongint functions require a "new" processor. From jkrell at elego.de Sun Mar 14 19:13:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:13:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181311.545C42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:13:11 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Preserve signedness a bit: 'Word64' => 'type' Probably doesn't matter. From jkrell at elego.de Sun Mar 14 19:17:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:17:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181743.7795F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:17:43 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: add CompareOpNames From hosking at cs.purdue.edu Sun Mar 14 19:31:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 14:31:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314154240.673312474001@birch.elegosoft.com> References: <20100314154240.673312474001@birch.elegosoft.com> Message-ID: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! On 14 Mar 2010, at 16:42, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 16:42:40 > > Added files: > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > Log message: > initial copy of Atomic.mg, this version won't have all the switch statements From hosking at elego.de Sun Mar 14 19:35:10 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314183510.9AAF22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:35:10 Modified files: cm3/m3-libs/m3core/src/atomic/: atomic.tmpl m3makefile Removed files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: Remove premature and irrational optimization. The compiler inlines the non-switch versions. There is no need for this overspecialization. From hosking at elego.de Sun Mar 14 19:49:31 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314184932.1A1AE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:49:31 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: No-one uses the strings. From jay.krell at cornell.edu Mon Mar 15 02:44:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:44:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> References: <20100314154240.673312474001@birch.elegosoft.com>, <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> Message-ID: The generated code was awful otherwise. All these big switch statements, only to do the same thing in each one. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 14 Mar 2010 14:31:35 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! > > On 14 Mar 2010, at 16:42, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/14 16:42:40 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > > > Log message: > > initial copy of Atomic.mg, this version won't have all the switch statements > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:45:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:45:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314184932.1A1AE2474001@birch.elegosoft.com> References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Mar 15 02:47:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 21:47:25 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: > I was using them. It is easy to imagine they'll be used again, while debugging. > > - Jay > > > Date: Sun, 14 Mar 2010 19:49:31 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/14 19:49:31 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: M3CG.i3 > > > > Log message: > > No-one uses the strings. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:54:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:54:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> References: <20100314184932.1A1AE2474001@birch.elegosoft.com>, , <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Message-ID: I removed them once I got my code working. But we have this sort of thing in general. - Jay From: hosking at cs.purdue.edu Date: Sun, 14 Mar 2010 21:47:25 -0400 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 15 03:29:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:29:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315022938.9D22A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:29:38 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: Fill in *a lot* more now that m3back implements everything. Notice that a few Refany cases are commented out, I couldn't figure out a way to call them (inc, dec, or, xor, and). From jkrell at elego.de Mon Mar 15 03:33:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315023307.9A5B62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:33:06 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: return rather than just eval IsLockFree() From jkrell at elego.de Mon Mar 15 03:40:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:40:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315024017.886B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:40:16 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: just one fence per fence test From jkrell at elego.de Mon Mar 15 10:55:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 10:55:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315095514.B7E772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 10:55:14 Modified files: cm3/scripts/python/: pylib.py Log message: fix long standing problem where do-pkg.py doesn't correctly order (or filter) packages given on command line From jkrell at elego.de Mon Mar 15 11:44:24 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 11:44:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315104424.0A2202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 11:44:24 Modified files: cm3/scripts/python/: do-cm3-all.py do-cm3-min.py do-cm3-std.py make-dist.py pylib.py Log message: order packages (some scenarios already did, but some did not) support package groups this makes do-pkg.py basically like do-cm3.cmd read scripts/pkginfo.txt instead of using local copy From jkrell at elego.de Mon Mar 15 14:20:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:20:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132035.6D8F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:20:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. From jkrell at elego.de Mon Mar 15 14:23:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:23:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132311.718CA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:23:11 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back a version: just always/save restore all 3 non-volatiles a compromise shortly that saves up front, possibly nop-ing out, and only restores what is needed From jkrell at elego.de Mon Mar 15 15:35:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:35:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143550.C8D2D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:35:50 Modified files: cm3/m3-sys/m3objfile/src/: NTObjFile.m3 M3ObjFile.i3 Log message: provide a function 'backup()' that lets caller seek backwards from the cursor; this should afford m3back something cleaner in generating epilogues, though still not great From jkrell at elego.de Mon Mar 15 15:36:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:36:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143612.04DFD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:36:11 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: don't compile MasmObjFile, it isn't used From jkrell at elego.de Mon Mar 15 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315144014.C608D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:40:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: Do something cleaner when generating prologues. In the interest of an optimization that saves an instruction from many many (all?) functions, the original authors often produce an epilogue by punching through abstraction boundaries and using objfile.patch. Worse, they sometimes do that, sometimes use equivalent code that goes through the layers. With this change, instead, we backup(5) and then use the clearer version. Unfortunately, if nothing else done, that leaves us trying to fixup the branch that we wiped out (its use of the label to the end of function. So compensate slightly in Codex86.m3. This is trading one ugliness for another. Perhaps something better can be found. I had something that compared to last_exitbranch in codex86.m3 but that wasn't quite right and introduced e.g. one instruction difference in RTHeapMap.m3. From jkrell at elego.de Mon Mar 15 16:06:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:06:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315150635.6BAF82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:06:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: Remove from one to three instructions from small functions. By tracking which non-volatile registers are used and only saving/restoring them. Unfortunately, until we are more sophisticated, we have to pay for the size for the push instructions, but we nop them out if they aren't needed, and only generating the needed pops. (We should look into two and three byte nops, but presently I just use one byte nops. The pushes are each one instruction. Theoretically, nop is faster than push, though I should check. Plus, nop saves us from doing a pop.) Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. Register allocator should probably favor volatile registers over non-volatile. Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) I noticed an ancient bug in doing this work. Functions with >4K frames need to call chkstk or equivalent. Specifically, stack pages must be touched in order. call naturally touches a page. Or, side motivation: match what the C compiler does. It is correct. (See, we also reserve room for sub esp,foo, for 32bit foo, even though many functions save save 3 bytes and use an 8bit value and some unusual functions can skip the entire thing (if foo = 0)) We can issue errors for such functions and see if any turn up. See test case p234 (not commited yet). Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. corrupt, set_reg, movop1, load_ind should suffice. From jkrell at elego.de Mon Mar 15 16:12:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:12:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315151237.264CF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:12:36 Added files: cm3/m3-sys/m3tests/src/p2/p234/: Main.m3 m3makefile Log message: add test that uses or doesn't use non-volatile registers perhaps should be moved to the "c for code" section We run it, make sure it doesn't crash, but the real point is codegen details. From jay.krell at cornell.edu Mon Mar 15 16:15:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 15:15:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100315150635.6BAF82474001@birch.elegosoft.com> References: <20100315150635.6BAF82474001@birch.elegosoft.com> Message-ID: diff attached, it is pretty simple > Date: Mon, 15 Mar 2010 16:06:35 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/15 16:06:35 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 > Stackx86.m3 > > Log message: > Remove from one to three instructions from small functions. > By tracking which non-volatile registers are used and only saving/restoring them. > Unfortunately, until we are more sophisticated, we have to pay for the size > for the push instructions, but we nop them out if they aren't needed, > and only generating the needed pops. (We should look into two and three > byte nops, but presently I just use one byte nops. The pushes are each > one instruction. Theoretically, nop is faster than push, though I should check. > Plus, nop saves us from doing a pop.) > > Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. > > Register allocator should probably favor volatile registers over non-volatile. > Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) > > I noticed an ancient bug in doing this work. > Functions with >4K frames need to call chkstk or equivalent. > Specifically, stack pages must be touched in order. call naturally > touches a page. Or, side motivation: match what the C compiler does. It is correct. > (See, we also reserve room for sub esp,foo, for 32bit foo, even > though many functions save save 3 bytes and use an 8bit value and > some unusual functions can skip the entire thing (if foo = 0)) > > We can issue errors for such functions and see if any turn up. > > See test case p234 (not commited yet). > > Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. > corrupt, set_reg, movop1, load_ind should suffice. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 15 16:26:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:26:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315152608.D59162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:26:08 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Be certain to get the register allocation correct for 64bit interlocked compare exchange. The code could be reduced but is very clear this way. We should probably have special flags (Force values) for ret64 (return_double_integer) as well as interlocked compare exchange double integer parameters. For now I infer these cases from aspects that could occur in less constrained situations, leading to unnecessary register moves (i.e. if we already for some reason have something in EAX:EDX, we shouldn't change it to EDX:EAX unless we actually have to.) From jkrell at elego.de Mon Mar 15 23:21:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 23:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315222155.833692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 23:21:55 Added files: cm3/m3-sys/m3back/src/doc/: frames.txt Log message: some notes on current, ideal, and correct patterns, based on C compiler output What we have is usually correct, rarely ideal, and sometimes wrong. In particular, we are not ideal for common case of functions with fewer than 128 bytes of locals. We use a 4 byte constant where a 1 byte constant suffices. Or the unusual cases of no locals/parameters. We are wrong for functions with more than 4K of locals: need to call chkstk. Let's at least try to fix the second case soon, but without making the usual cases larger. From jkrell at elego.de Tue Mar 16 11:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316103800.04B492474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:37:59 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: write debug output integers the old way: the new way isn't so important any longer, and it looks like this format *might* be readable From jkrell at elego.de Tue Mar 16 11:42:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:42:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104247.02FCC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:42:46 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: fix (looks like I had copied from release?) From jkrell at elego.de Tue Mar 16 11:45:14 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:45:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104514.4BE4D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:45:14 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: slightly more vertically dense: save two lines From jkrell at elego.de Tue Mar 16 14:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 14:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316132706.D92102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 14:27:06 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: put back MasmObjFile for m3staloneback From jkrell at elego.de Tue Mar 16 17:29:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 17:29:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316162908.048D22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 17:29:07 Modified files: cm3/scripts/python/: pylib.py Log message: reasonable hack: ignore package names that end '.py' -- these are argv[0] From wagner at elego.de Tue Mar 16 22:51:59 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 16 Mar 2010 22:51:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316215159.9892F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/16 22:51:59 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: list Debian and MSI packages, too From jkrell at elego.de Wed Mar 17 17:33:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:33:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163344.780D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:33:44 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: use fork1() on Solaris in case built/running on pre-Solaris 2.10 and using the libraries in which fork==forkall (at some point should setup a pre 2.10 machine?) From jkrell at elego.de Wed Mar 17 17:35:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:35:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163532.B486E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:35:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: if defined => ifdef in previous From jkrell at elego.de Wed Mar 17 18:02:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:02:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170257.1CB462474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:02:57 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: for now put back set_member and set_singleton, so I haven't to rebuild everything From jkrell at elego.de Wed Mar 17 18:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170346.8E99C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:03:46 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: Longer name for parameter From pmckinna at elego.de Thu Mar 18 11:50:17 2010 From: pmckinna at elego.de (Peter McKinna) Date: Thu, 18 Mar 2010 11:50:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105018.01F342474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 10/03/18 11:50:17 Modified files: cm3/m3-comm/netobj/tests/perf/src/: m3makefile Log message: Fixed quotes From jkrell at elego.de Thu Mar 18 11:55:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 11:55:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105548.99CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 11:55:48 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: cleanup to use and factor out the "safe double free" pattern, e.g. procedure Close(var i) if i >= 0 close(i) i = -1 This does not address the pthreads hangs. From jkrell at elego.de Thu Mar 18 12:12:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 12:12:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318111213.C0B7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 12:12:13 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: small part of cvsup fix - initialize stuff in InitActivations instead of depending on static initialization It used to look like this anyway I think. - change some variables to CARDINAL From jkrell at elego.de Fri Mar 19 18:07:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 19 Mar 2010 18:07:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100319170759.3D67D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/19 18:07:59 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix newlines From jkrell at elego.de Sat Mar 20 08:10:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:10:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320071045.ED2692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:10:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back div/mod helpers for compatibility with older backend, I was still using them a while From jkrell at elego.de Sat Mar 20 08:56:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:56:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075611.0313F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:56:10 Added files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add some tests for set_lt, le, gt, le; I find this code a bit hard to understand From jkrell at elego.de Sat Mar 20 08:59:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:59:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075916.38C252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:59:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: implement set_gt(a,b) as set_lt(b,a) implement set_ge(a,b) as set_le(b,a) Really the frontend or backend should make this transform. From jkrell at elego.de Sat Mar 20 09:22:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 9:22:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320082218.82AA42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 09:22:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test; not seeing commit mail? From jay.krell at cornell.edu Sat Mar 20 09:21:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Mar 2010 08:21:58 +0000 Subject: [M3commit] test Message-ID: test; not seeing commit mail? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mand at elego.de Sat Mar 20 19:20:27 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:20:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182027.3E2762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:20:27 Modified files: cm3/: README Log message: Trivial text edit for test purposes. Sorry for the spam. From mand at elego.de Sat Mar 20 19:21:58 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:21:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182158.C7A652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:21:58 Modified files: cm3/: README Log message: Cleanin up after commit mail test.... From jkrell at elego.de Sat Mar 20 21:40:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 21:40:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320204039.993E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 21:40:39 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: new file, empty to start From jkrell at elego.de Sun Mar 21 02:35:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 2:35:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321013545.5C8252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 02:35:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test commit mail; some recent commits here didn't show up; no diff here From jkrell at elego.de Sun Mar 21 10:28:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092809.55CF72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:04 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: fix making Debian packages From jkrell at elego.de Sun Mar 21 10:28:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092836.82E552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:36 Modified files: cm3/scripts/python/: pylib.py Log message: fix making Debian packages From jkrell at elego.de Mon Mar 22 05:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 22 Mar 2010 5:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100322042154.CAA7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/22 05:21:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcess.m3 Log message: remove newlines at end of file From hosking at elego.de Thu Mar 25 02:45:16 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 25 Mar 2010 2:45:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100325014517.5E98A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/25 02:45:16 Modified files: cm3/m3-sys/m3front/src/misc/: M3Front.m3 Log message: We have a decent collector. From mand at elego.de Fri Mar 26 22:53:59 2010 From: mand at elego.de (Michael Anderson) Date: Fri, 26 Mar 2010 22:53:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100326215400.0AC302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/26 22:53:59 Modified files: cm3/www/: todo.html Log message: Trivial text edit to test after server upgrade. Sorry for the spam. From jkrell at elego.de Sat Mar 27 09:56:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085615.C13DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:15 Modified files: cm3/m3-tools/cvsup/client/src/: Auth.i3 Auth.m3 BackoffTimer.i3 BackoffTimer.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 Detailer.i3 Detailer.m3 EventSync.i3 EventSync.m3 FSClient.i3 FSClient.m3 FileUpdater.i3 FileUpdater.m3 Fixup.i3 Main.m3 RCSUpdater.i3 RCSUpdater.m3 Receive.i3 Receive.m3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 SupFile.i3 SupFile.m3 SupGUI.i3 SupGUI.m3 SupGUIFake.m3 TextPortLogger.i3 TextPortLogger.m3 TextVBTLogger.i3 TextVBTLogger.m3 TreeList.i3 TreeList.m3 Updater.i3 Updater.m3 Version.i3 cm3/m3-tools/cvsup/cvpasswd/src/: Main.m3 Secret.i3 Secret.m3 Upass.i3 cm3/m3-tools/cvsup/server/src/: AccessRules.i3 AccessRules.m3 ClassDB.i3 ClassDB.m3 ClientClass.i3 ClientClass.m3 FSServer.i3 FSServer.m3 FSServerRep.i3 FSServerU.m3 FileInfo.i3 FileInfo.m3 Main.m3 ParsedDelta.i3 ParsedDelta.m3 Passwd.i3 Passwd.m3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 Version.i3 cm3/m3-tools/cvsup/suplib/src/: Attic.i3 Attic.m3 AuthMD5.i3 AuthMD5.m3 CText.i3 CVProto.i3 CVProto.m3 CVTree.i3 CVTree.m3 ChannelMux.i3 ChannelMux.m3 DevT.i3 DirEntry.i3 DirEntry.m3 ErrMsg.i3 ErrMsg.m3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 ExecRec.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.i3 FileID.m3 FileStatus.i3 FileStatus.m3 FileStatusRaw.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 GzipError.i3 GzipError.m3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 IOWatchDog.i3 IOWatchDog.m3 LockFile.i3 LockFile.m3 Logger.i3 Logger.m3 LoggerClass.i3 MD5.i3 MD5.m3 MD5Digest.i3 MD5Digest.m3 MD5Wr.i3 MD5Wr.m3 MySyslog.i3 PathComp.i3 PathComp.m3 ProcTitle.i3 RCSAccess.i3 RCSAccess.m3 RCSDate.i3 RCSDate.m3 RCSDelta.i3 RCSDelta.m3 RCSDeltaClass.i3 RCSEdit.i3 RCSError.i3 RCSFile.i3 RCSFile.m3 RCSKeyword.i3 RCSKeyword.m3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSRevNum.i3 RCSRevNum.m3 RCSString.i3 RCSString.m3 RCSTag.i3 RCSTag.m3 Reaper.i3 Reaper.m3 RsyncBlock.i3 RsyncBlock.m3 RsyncFile.i3 RsyncFile.m3 SigHandler.i3 SigHandler.m3 SplitLogger.i3 SplitLogger.m3 StatusFile.i3 StatusFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 TokScan.i3 TokScan.m3 Uglob.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 UnixMisc.i3 UnixMisc.m3 WatchDog.i3 WatchDog.m3 WrLogger.i3 WrLogger.m3 cm3/m3-tools/cvsup/suplib/src/FreeBSD/: FileAttrOS.i3 FileAttrOS.m3 ProcTitle.m3 UProcTitle.i3 cm3/m3-tools/cvsup/suplib/src/POSIX/: FileAttrOS.m3 ProcTitle.m3 cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: DevT.m3 cm3/m3-tools/cvsup/suplib/src/text_cm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suplib/src/text_pm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suptcp/src/POSIX/: SockOpt.i3 SockOptFBSD.m3 SockOptOther.m3 cm3/m3-tools/cvsup/suptcp/src/common/: StreamRd.i3 StreamRdClass.i3 StreamRdClass.m3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPMisc.i3 Log message: remove $Id$, see scripts/python/remove-id.py From jkrell at elego.de Sat Mar 27 09:56:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085649.D7D972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:49 Added files: cm3/scripts/python/: remove-id.py Log message: automate removing $Id$ From jkrell at elego.de Sun Mar 28 01:13:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001322.9516B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:13:22 Modified files: cm3/m3-tools/cvsup/: Makefile cm3/m3-tools/cvsup/client/: Makefile cm3/m3-tools/cvsup/client/src/: m3makefile cm3/m3-tools/cvsup/config/src/: m3makefile cm3/m3-tools/cvsup/cvpasswd/: Makefile cm3/m3-tools/cvsup/cvpasswd/src/: m3makefile cm3/m3-tools/cvsup/doc/: Makefile cm3/m3-tools/cvsup/server/: Makefile cm3/m3-tools/cvsup/server/src/: m3makefile cm3/m3-tools/cvsup/suplib/: Makefile cm3/m3-tools/cvsup/suplib/src/: m3makefile cm3/m3-tools/cvsup/suplib/src/FreeBSD/: m3makefile cm3/m3-tools/cvsup/suplib/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: m3makefile cm3/m3-tools/cvsup/suplib/src/libglob/: m3makefile cm3/m3-tools/cvsup/suplib/src/libmd/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_cm3/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_pm3/: m3makefile cm3/m3-tools/cvsup/suptcp/: Makefile cm3/m3-tools/cvsup/suptcp/src/: m3makefile cm3/m3-tools/cvsup/suptcp/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suptcp/src/common/: m3makefile Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001541.22C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:15:41 Modified files: cm3/m3-tools/cvsup/: Acknowledgments Announce Blurb Install cm3/m3-tools/cvsup/client/src/: SyncQueue.ig SyncQueue.mg cm3/m3-tools/cvsup/doc/: Attributes Checkouts Protocol faqgen.awk cm3/m3-tools/cvsup/examples/: README cm3/m3-tools/cvsup/suplib/src/: Merger.ig Merger.mg UnixMiscC.c cm3/m3-tools/cvsup/suplib/src/libglob/: fnmatch.c fnmatch.h cm3/m3-tools/cvsup/suplib/src/libmd/: md5.h md5c.c cm3/m3-tools/cvsup/suptcp/src/: README cm3/m3-tools/cvsup/suptcp/src/POSIX/: SupTCP.m3 SupTCPHack.i3 SupTCPHack.m3 SupTCPHackNull.m3 SupTCPPosix.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:17:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:17:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001701.646132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:17:01 Modified files: cm3/m3-tools/cvsup/client/src/: SupGUI.fv cvsup.1 syncqueue.tmpl cm3/m3-tools/cvsup/contrib/cvsup2httplog/: cvsup2httplog cm3/m3-tools/cvsup/contrib/cvsupchk/: cvsupchk cm3/m3-tools/cvsup/cvpasswd/src/: cvpasswd.1 cm3/m3-tools/cvsup/quake/: cvsup.quake cm3/m3-tools/cvsup/server/src/: cvsupd.8 cm3/m3-tools/cvsup/suplib/src/: merger.tmpl cm3/m3-tools/cvsup/suplib/src/libmd/: md5.copyright md5hl.c cm3/m3-tools/cvsup/suptcp/src/common/: SupTCP.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 11:07:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:07:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328090717.258542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:07:17 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: no need for an "object", just make everything global From jkrell at elego.de Sun Mar 28 11:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328091049.DDB102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:10:49 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: expand critical section in shutdown From jkrell at elego.de Sun Mar 28 11:31:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:31:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093100.CC7712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:31:00 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 RTProcess.i3 RTProcessC.c m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: cvsup/pthread_atfork fixes From jkrell at elego.de Sun Mar 28 11:33:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093313.0DA382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:33:11 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: fix to work with pthreads, or with user thread revision, where fork() doesn't leave all threads running From jkrell at elego.de Sun Mar 28 12:07:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100747.0C4422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:07:46 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 m3core.h Log message: partial merge from head: add calling conventions From jkrell at elego.de Sun Mar 28 12:09:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:09:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100907.E147B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:09:07 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 platforms.quake Log message: copy from head: add PPC64_DARWIN From jkrell at elego.de Sun Mar 28 12:13:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:13:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328101341.497F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:13:41 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.m3 Log message: copy from head: whitespace only From jkrell at elego.de Sun Mar 28 12:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103449.63A522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:34:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.i3 m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: Tag: release_branch_cm3_5_8 ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Added files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcessC.c Log message: merge cvsup/pthread_atfork changes from head to release From jkrell at elego.de Sun Mar 28 12:36:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:36:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103619.DF5F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:36:19 Modified files: cm3/m3-tools/cvsup/suplib/src/: Tag: release_branch_cm3_5_8 SigHandler.m3 Log message: copy from head for pthreads compatibility (fork() leaves just one thread, userthreads this way now too) From jkrell at elego.de Sun Mar 28 12:38:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:38:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103858.2C6222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:38:58 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Log message: fix From wagner at elego.de Sun Mar 28 15:07:02 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328130702.734C62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:07:02 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: temporarily turn on command tracing From wagner at elego.de Sun Mar 28 15:33:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:33:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328133324.CBC312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:33:24 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: disable command tracing again From jkrell at elego.de Mon Mar 29 20:47:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 20:47:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329184755.5D2D4CC37C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 20:47:55 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: change Multiplier from a variable to a constant From jkrell at elego.de Mon Mar 29 21:05:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 21:05:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329190516.7304F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 21:05:16 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: make it clearer From hosking at elego.de Mon Mar 29 21:13:19 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 29 Mar 2010 21:13:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329191319.BE5EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/29 21:13:19 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: Cleaner code (don't obfuscate history). No need for initialization of fields when the initializer can do that. From jkrell at elego.de Tue Mar 30 11:46:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 30 Mar 2010 11:46:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100330094652.3FF612474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/30 11:46:52 Modified files: cm3/m3-libs/m3core/src/types/: m3makefile Log message: include Int64 on NT386 From jkrell at elego.de Wed Mar 31 15:17:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:17:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331131727.7D1E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:17:27 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 UnixC.c Log message: add Unix.tell, at least for Win32 and Solaris, real goal is to add minimal Unix on Win32, and then run libm3 tests From jkrell at elego.de Wed Mar 31 15:34:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133421.BBF382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:34:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: Unix__tell here too From jkrell at elego.de Wed Mar 31 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133543.E90102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:35:43 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usocket.c m3makefile cm3/m3-libs/m3core/src/unix/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/WIN32/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/WIN32/: Unix.i3 Uuio.i3 Log message: greatly increase availability of src/unix on Win32, as much of it is actually provided by msvcr*dll From jkrell at elego.de Wed Mar 31 15:54:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:54:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331135417.510EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:54:16 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: better fallbacks for InitUserName, InitUserHome From jkrell at elego.de Mon Mar 1 05:34:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 5:34:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301043402.65E792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 05:34:02 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: move e_test use down below definition, so it works From jkrell at elego.de Mon Mar 1 11:55:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:55:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105536.BA6F32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:55:36 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: VAL(filesize, CARDINAL) to fix compilation From jkrell at elego.de Mon Mar 1 11:56:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:56:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105614.DD2B52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:56:14 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: INTEGER just in case From jkrell at elego.de Mon Mar 1 11:57:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:57:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105754.A5D862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:57:54 Modified files: cm3/m3-libs/libm3/tests/os/src/: Tag: release_branch_cm3_5_8 OSTest.m3 Log message: from head: VAL(filesize, INTEGER) to fix compilation From jkrell at elego.de Mon Mar 1 13:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 13:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301125437.9F27D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 13:54:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: work in progress to inline all 64bit shifts (and then rotates) the 64bit shift code in particular in the AMD manual is around 6 instruction however before we do that: teach unOp about double shift (aka shift by ecx) not yet used, as these cases still call functions split up the double ops into separate functions for readability: not_double, add_double, add_double_immediate, etc. (not, negate, add, subtract, compare, immediate and not; bigger things like multiply/divide generate function calls at a higher level, currently; given that our complicated single precision divide was inlined, probably will inline that for double, probably multiple too; while the result is bloated, I like the idea of reducing hand.c, and longint use on 32bit targets maybe ok to bloat?) also goal to have less duplication of the various logic such as left vs. right vs. "signed" shift, the compares to 32, 64, etc. at least move the code into fewer functions also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split into something that seems less hoky. Part of the issue is that other than oNOT, and separate functions like swapOp, movOp, nothing is really "just loop over the parts" From jay.krell at cornell.edu Mon Mar 1 13:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Mar 2010 12:57:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100301125437.9F27D2474001@birch.elegosoft.com> References: <20100301125437.9F27D2474001@birch.elegosoft.com> Message-ID: attached btw, other than the commit mail, the changelog should have a clickable link. > Date: Mon, 1 Mar 2010 13:54:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/01 13:54:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 > > Log message: > work in progress to inline all 64bit shifts (and then rotates) > the 64bit shift code in particular in the AMD manual is around 6 instruction > > however before we do that: > > teach unOp about double shift (aka shift by ecx) > not yet used, as these cases still call functions > > split up the double ops into separate functions for readability: > not_double, add_double, add_double_immediate, etc. > (not, negate, add, subtract, compare, immediate and not; bigger > things like multiply/divide generate function calls at a higher level, currently; > given that our complicated single precision divide was inlined, probably will > inline that for double, probably multiple too; while the result is bloated, > I like the idea of reducing hand.c, and longint use on 32bit targets > maybe ok to bloat?) > > also goal to have less duplication of the various logic such > as left vs. right vs. "signed" shift, the compares to 32, 64, etc. > at least move the code into fewer functions > > also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split > into something that seems less hoky. Part of the issue is that > other than oNOT, and separate functions like swapOp, movOp, nothing is really > "just loop over the parts" > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 1 15:25:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 15:25:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301142522.44AD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 15:25:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: fix and slightly extend From jkrell at elego.de Tue Mar 2 13:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125012.EDEEE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:50:12 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: case and whitespace From jkrell at elego.de Tue Mar 2 13:52:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:52:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125229.A8E4B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:52:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: somewhat consolidate shifting code no more "binOpWithShiftCount" inline all 64bit shifts, even when no constants involved (constants get inlined better) worst cases: shift right 64 (from the AMD manual): 00002217: 0F AD D3 shrd ebx,edx,cl 0000221A: D3 EA shr edx,cl 0000221C: F6 C1 20 test cl,20h 0000221F: 74 04 je 00002225 00002221: 8B DA mov ebx,edx 00002223: 33 D2 xor edx,edx 00002225: shift left 64 (from the AMD manual): 0000244B: 0F A5 DA shld edx,ebx,cl 0000244E: D3 E3 shl ebx,cl 00002450: F6 C1 20 test cl,20h 00002453: 74 04 je 00002459 00002455: 8B D3 mov edx,ebx 00002457: 33 DB xor ebx,ebx 00002459: Those sequences are quite subtle. I'm not sure I understand. Shift by between 32 and 63: The "wrong" register is shifted, but it is done modulo-32, so the correct result is had, in the "wrong" register then the register is moved to its correct place. That is: edx:eax << 33 is straightforwardly, after testing if the shift count is >32: edx = eax edx <<= 1 (shift count - 32) eax = 0 however the above does the shift before the move, since the modulo makes it correct: eax <<= (33 % 32) which is eax <<= 1 edx = eax eax = 0 The way it detects >=32 is very subtle to me. It checks if the 32 bit is set. If it is not set, the work is deemed done. Any value in 33-64 inclusive has it set, and gets shifted an extra 32, via mov and xor. Any value in 0-31 has it clear, done. The case of 32 exactly works with the first two instructions. I guess. I didn't come up with this, it is in the AMD optimization manual. wierdo shift 32: (no change) 00006CD4: 83 F9 00 cmp ecx,0 00006CD7: 7D 0F jge 00006CE8 00006CD9: F7 D9 neg ecx 00006CDB: 83 F9 20 cmp ecx,20h 00006CDE: 7D 04 jge 00006CE4 00006CE0: D3 EB shr ebx,cl 00006CE2: EB 0B jmp 00006CEF 00006CE4: 33 DB xor ebx,ebx 00006CE6: EB 07 jmp 00006CEF 00006CE8: 83 F9 20 cmp ecx,20h 00006CEB: 7D F7 jge 00006CE4 00006CED: D3 E3 shl ebx,cl 00006CEF: wierdo shift 64: 000071E9: 83 F9 00 cmp ecx,0 000071EC: 7D 1D jge 0000720B 000071EE: F7 D9 neg ecx 000071F0: 83 F9 40 cmp ecx,40h 000071F3: 7D 10 jge 00007205 000071F5: 0F AD F3 shrd ebx,esi,cl 000071F8: D3 EE shr esi,cl 000071FA: F6 C1 20 test cl,20h 000071FD: 74 04 je 00007203 000071FF: 8B DE mov ebx,esi 00007201: 33 F6 xor esi,esi 00007203: EB 19 jmp 0000721E 00007205: 33 DB xor ebx,ebx 00007207: 33 F6 xor esi,esi 00007209: EB 13 jmp 0000721E 0000720B: 83 F9 40 cmp ecx,40h 0000720E: 7D F5 jge 00007205 00007210: 0F A5 DE shld esi,ebx,cl 00007213: D3 E3 shl ebx,cl 00007215: F6 C1 20 test cl,20h 00007218: 74 04 je 0000721E 0000721A: 8B F3 mov esi,ebx 0000721C: 33 DB xor ebx,ebx 0000721E: as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) We might as well first compare to -64 before the negate, same instruction count, more obviously correct. there are a few extra instructions in wierd shift 64, the parts that shift by more than 32 or more than 64 have common pieces that can be shared ("tail merged") and there is a branch to a jmp We should see about optimizing the wierd shift 64 case. A few instructions can easily be saved. From jkrell at elego.de Tue Mar 2 13:59:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:59:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125931.619312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:59:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove m3_shift64, which for the record was: uint64 __stdcall m3_shift64(uint64 a, int b) { if (b >= 64 || b <= -64) a = 0; else if (b > 0) a <<= b; else if (b < 0) a >>= -b; return a; } _m3_shift64 at 12: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 00000006: 8D 41 3F lea eax,[ecx+3Fh] 00000009: 83 F8 7E cmp eax,7Eh 0000000C: 77 1C ja 0000002A 0000000E: 8B 45 08 mov eax,dword ptr [ebp+8] 00000011: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000014: 85 C9 test ecx,ecx 00000016: 7E 07 jle 0000001F 00000018: E8 00 00 00 00 call __allshl 0000001D: EB 0F jmp 0000002E 0000001F: 7D 0D jge 0000002E 00000021: F7 D9 neg ecx 00000023: E8 00 00 00 00 call __aullshr 00000028: EB 04 jmp 0000002E 0000002A: 33 C0 xor eax,eax 0000002C: 33 D2 xor edx,edx 0000002E: 5D pop ebp 0000002F: C2 0C 00 ret 0Ch From jay.krell at cornell.edu Tue Mar 2 14:18:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Mar 2010 13:18:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100302125229.A8E4B2474001@birch.elegosoft.com> References: <20100302125229.A8E4B2474001@birch.elegosoft.com> Message-ID: roughly the attached, though I know the case/space diff is also there It's pretty hard to find this stuff via cvsweb/changelog/etc..... - Jay > Date: Tue, 2 Mar 2010 13:52:29 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/02 13:52:29 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.i3 Stackx86.m3 > > Log message: > somewhat consolidate shifting code > > no more "binOpWithShiftCount" > > inline all 64bit shifts, even when no constants involved > (constants get inlined better) > > worst cases: > > shift right 64 (from the AMD manual): > 00002217: 0F AD D3 shrd ebx,edx,cl > 0000221A: D3 EA shr edx,cl > 0000221C: F6 C1 20 test cl,20h > 0000221F: 74 04 je 00002225 > 00002221: 8B DA mov ebx,edx > 00002223: 33 D2 xor edx,edx > 00002225: > > shift left 64 (from the AMD manual): > 0000244B: 0F A5 DA shld edx,ebx,cl > 0000244E: D3 E3 shl ebx,cl > 00002450: F6 C1 20 test cl,20h > 00002453: 74 04 je 00002459 > 00002455: 8B D3 mov edx,ebx > 00002457: 33 DB xor ebx,ebx > 00002459: > > Those sequences are quite subtle. > I'm not sure I understand. > Shift by between 32 and 63: > The "wrong" register is shifted, but it is done modulo-32, > so the correct result is had, in the "wrong" register > then the register is moved to its correct place. > That is: > edx:eax << 33 > is straightforwardly, after testing if the shift count is >32: > edx = eax > edx <<= 1 (shift count - 32) > eax = 0 > however the above does the shift before the move, > since the modulo makes it correct: > eax <<= (33 % 32) which is eax <<= 1 > edx = eax > eax = 0 > > The way it detects >=32 is very subtle to me. > It checks if the 32 bit is set. > If it is not set, the work is deemed done. > Any value in 33-64 inclusive has it set, and gets shifted an extra 32, > via mov and xor. > Any value in 0-31 has it clear, done. > The case of 32 exactly works with the first two instructions. > > I guess. > I didn't come up with this, it is in the AMD optimization manual. > > wierdo shift 32: (no change) > 00006CD4: 83 F9 00 cmp ecx,0 > 00006CD7: 7D 0F jge 00006CE8 > 00006CD9: F7 D9 neg ecx > 00006CDB: 83 F9 20 cmp ecx,20h > 00006CDE: 7D 04 jge 00006CE4 > 00006CE0: D3 EB shr ebx,cl > 00006CE2: EB 0B jmp 00006CEF > 00006CE4: 33 DB xor ebx,ebx > 00006CE6: EB 07 jmp 00006CEF > 00006CE8: 83 F9 20 cmp ecx,20h > 00006CEB: 7D F7 jge 00006CE4 > 00006CED: D3 E3 shl ebx,cl > 00006CEF: > > wierdo shift 64: > 000071E9: 83 F9 00 cmp ecx,0 > 000071EC: 7D 1D jge 0000720B > 000071EE: F7 D9 neg ecx > 000071F0: 83 F9 40 cmp ecx,40h > 000071F3: 7D 10 jge 00007205 > 000071F5: 0F AD F3 shrd ebx,esi,cl > 000071F8: D3 EE shr esi,cl > 000071FA: F6 C1 20 test cl,20h > 000071FD: 74 04 je 00007203 > 000071FF: 8B DE mov ebx,esi > 00007201: 33 F6 xor esi,esi > 00007203: EB 19 jmp 0000721E > 00007205: 33 DB xor ebx,ebx > 00007207: 33 F6 xor esi,esi > 00007209: EB 13 jmp 0000721E > 0000720B: 83 F9 40 cmp ecx,40h > 0000720E: 7D F5 jge 00007205 > 00007210: 0F A5 DE shld esi,ebx,cl > 00007213: D3 E3 shl ebx,cl > 00007215: F6 C1 20 test cl,20h > 00007218: 74 04 je 0000721E > 0000721A: 8B F3 mov esi,ebx > 0000721C: 33 DB xor ebx,ebx > 0000721E: > > as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) > We might as well first compare to -64 before the negate, same instruction count, more > obviously correct. > there are a few extra instructions in wierd shift 64, the parts that > shift by more than 32 or more than 64 have common pieces that > can be shared ("tail merged") and there is a branch to a jmp > > We should see about optimizing the wierd shift 64 case. > A few instructions can easily be saved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Tue Mar 2 14:46:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:46:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134623.1FB6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:46:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: source of the new bits in shift double must a register, can't be memory, so remove two lines that handle the memory case From jkrell at elego.de Tue Mar 2 14:48:49 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:48:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134849.6DD6B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:48:49 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: 'shift_double_tail' ended up with only one caller -- 'shift_double_ecx' -- inline it here (these are small functions, point is readability, not perf) From jkrell at elego.de Tue Mar 2 14:52:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:52:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302135258.352D82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:52:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: some tersification, not sure this is a good idea -- omit types in VAR, initialize in VAR instead of body From jkrell at elego.de Tue Mar 2 15:14:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141404.128992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:04 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 TIntN.i3 TWordN.i3 TWordN.m3 Log message: avoid runtime error (range error) in compiler when user shifts by too large of a number leave it as a warning, generate unoptimized code, and let the runtime error occur in user's program From jkrell at elego.de Tue Mar 2 15:14:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141434.4A5B42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:34 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: whitespace to my liking From jkrell at elego.de Wed Mar 3 10:21:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:21:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092142.7B7862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it From jkrell at elego.de Wed Mar 3 10:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092303.41FDD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> in zero_n; gcc backend implements it incorrectly and it is never used From jkrell at elego.de Wed Mar 3 12:09:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:09:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303110910.8DB8F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:09:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: extend test case (a bit annoyingly long already) attempting to insert/extract upper bits I haven't yet extended the bit offsets before I get there, this extension already is exhibiting two behaviors that need further investigation, and is therefore not quite as extended as intended (the commenting out of flipA) in the 32bit insert, I get a subrange error if I allow the flipA Perhaps I just don't understand something. in the 64bit insert, I get an error in the backend if I allow flipA and the code looks a little wrong; it is having trouble allocating registers/temps will test with gcc for one thing and with the release branch the 64bit problem doesn't seem to do with 64bits so much as "complex" expressions in function calls (sounds wrong, but no matter, I'll investigate) From jkrell at elego.de Wed Mar 3 12:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303112525.6BFCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: try make it more portable, and now also reduce runtime significantly by removing coverage that should be redundant From jkrell at elego.de Wed Mar 3 12:31:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:31:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303113140.111092474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:31:39 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: more portability, more shrinkage From jkrell at elego.de Wed Mar 3 12:44:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:44:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114404.568562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:44:04 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: more portable From jkrell at elego.de Wed Mar 3 12:45:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:45:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114545.5705C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:45:45 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: -lp and -less-portable synonyms for -'include-less-portable-output From jkrell at elego.de Wed Mar 3 12:47:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:47:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114703.EA9F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:47:03 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:48:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:48:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114842.EAA0B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:48:42 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115437.4B8842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:54:37 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 12:56:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:56:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115640.C3CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:56:40 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 13:05:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:05:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120553.8364B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:05:53 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: store result in INTEGER instead of CARDINAL to fix the one problem From jkrell at elego.de Wed Mar 3 13:08:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:08:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120822.1E66F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:08:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update amd64 output From jkrell at elego.de Wed Mar 3 13:10:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:10:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121035.627AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:10:35 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: add ASSERT FALSE after a new problem test p227 finds if you enable flipA in the LONGINT part of TestInsert From jkrell at elego.de Wed Mar 3 13:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121455.71FC02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:14:55 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: don't bother printing the 0 cases that we an just assert: wow that cuts things down! From jkrell at elego.de Wed Mar 3 13:17:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:17:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121710.A2D102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:17:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: oops From jkrell at elego.de Wed Mar 3 13:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121809.298F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:18:09 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update (was small because of assertion failure, alas) From jkrell at elego.de Wed Mar 3 13:19:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:19:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121956.76C162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:19:56 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Log message: update output From jkrell at elego.de Wed Mar 3 14:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 14:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303131128.2F6D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 14:11:27 Modified files: cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.m3 Log message: untested port small fix from head for initializing longint, see revision 1.34 From hosking at cs.purdue.edu Wed Mar 3 16:57:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 10:57:32 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100303092142.7B7862474001@birch.elegosoft.com> References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 3 17:02:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 11:02:36 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/03 10:21:42 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> zero_n is incorrect and never used, put gcc_assert(0) in it > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Wed Mar 3 17:44:58 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:44:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164458.6DE562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:44:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Detangle spaghetti code: flags are evil! Verbosity is sometimes the essence of clarity when it permits context-freedom. From hosking at elego.de Wed Mar 3 17:49:28 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164928.7B6322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:49:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Make it compile! From hosking at elego.de Wed Mar 3 17:53:51 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:53:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303165351.7B4F02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:53:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Reorganise slightly so diffs work more nicely with past versions. From hosking at elego.de Wed Mar 3 18:23:21 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172321.4EEC52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:23:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Let's respect the definition of BYTESIZE (in case it ever were to change). Also, why the nasty constant folding in index_address? Let gcc's constant folders take care of it (inside m3_build2). From hosking at elego.de Wed Mar 3 18:24:14 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:24:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172415.06D6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:24:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Fix warning. From jay.krell at cornell.edu Thu Mar 4 00:45:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Mar 2010 23:45:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Thu Mar 4 04:15:49 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 4 Mar 2010 4:15:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304031550.08E012474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/04 04:15:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Cleanup. Fix m3cg_zero_n. From hosking at cs.purdue.edu Thu Mar 4 04:29:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 22:29:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:31:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:31:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote:Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 07:46:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 01:46:53 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:57:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:57:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> , <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> Message-ID: It is still not possible to test. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Thu, 4 Mar 2010 01:46:53 -0500 CC: m3commit at elegosoft.com To: jay.krell at cornell.edu I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 08:16:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 07:16:20 +0000 Subject: [M3commit] m3_build vs. build in parse.c? Message-ID: Why use one vs. the other? It appears that they are equivalent *except* that m3_build attempts to optimize, but falls back to build if it can't. That is, m3_build calls fold_build. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 08:58:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 02:58:30 -0500 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: References: Message-ID: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. On 4 Mar 2010, at 02:16, Jay K wrote: > Why use one vs. the other? > It appears that they are equivalent *except* that m3_build attempts to optimize, > but falls back to build if it can't. > > That is, m3_build calls fold_build. > > - Jay > > > > From jay.krell at cornell.edu Thu Mar 4 09:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 08:46:06 +0000 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> References: , <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> Message-ID: Why not always call m3_build? Why ever call build? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 4 Mar 2010 02:58:30 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] m3_build vs. build in parse.c? > > So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. > > On 4 Mar 2010, at 02:16, Jay K wrote: > > > Why use one vs. the other? > > It appears that they are equivalent *except* that m3_build attempts to optimize, > > but falls back to build if it can't. > > > > That is, m3_build calls fold_build. > > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Mar 4 12:43:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 04 Mar 2010 12:43:52 +0100 Subject: [M3commit] lost commit messages: Fwd: 4 Forwarded Messages Message-ID: <20100304124352.acni7mp0nk8k0wk4@mail.elegosoft.com> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:57:48 +0100 Size: 2468 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:55:52 +0100 Size: 2523 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:51:37 +0100 Size: 2452 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:50:37 +0100 Size: 2518 URL: From jkrell at elego.de Thu Mar 4 13:57:24 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 13:57:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304125724.807162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 13:57:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: eliminate calls to set_member and set_singleton the unoptimized code for set_member is decent, though not nearly as good as m3back (m3back uses bts and bt) the code for set_singleton never seems particularly great but ok I tried a lot with array_ref, and bit_field ref, no luck the use of stabilize_reference (or build(save_expr)) does help In particular in set_singleton, I can't get the compiler to "or into memory", never as good even when optimized as optimized C. The C compiler's best: void set_singleton(unsigned* a, unsigned b) { a[b / 32] |= (1 << (b % 32)); } pushl %ebp movl %esp, %ebp movl 12(%ebp), %ecx movl 8(%ebp), %eax movl %ecx, %edx andl $31, %ecx shrl $5, %edx leal (%eax,%edx,4), %edx << not able to get this from cm3cg movl $1, %eax sall %cl, %eax orl %eax, (%edx) << not able to get this from cm3cg popl %ebp ret I can never get it to use lea with both a scale and an address. I will try a bit more, but this version should do. In particular I was using bit_field_ref with size 1, setting it to 1, maybe a full word will work better. This variation also has an advantage over some in that it shouldn't break pickles. This might be considered a significant size deoptimization and better off before, calling a function. tested on LINUXLIBC6 (so far) From jkrell at elego.de Thu Mar 4 14:19:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 14:19:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304131906.E94622474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 14:19:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove set_singleton and set_member From jkrell at elego.de Thu Mar 4 15:41:22 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 15:41:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304144122.CF96B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 15:41:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: stylistic variation on previous From rodney_bates at lcwb.coop Thu Mar 4 21:45:12 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 04 Mar 2010 14:45:12 -0600 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <4B901BD8.10403@lcwb.coop> Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. I am with Tony on this one. Well-designed code has always had places where it will handle a more general input space than current use-cases demand. Always removing everything from what is handled reflects the view that a program is a one-time thing that never changes. Putting in some things that follow a consistent general pattern reflects the view that a program is an evolving thing. Excepting a very few programs that are either trivial or very little-used, the latter assumption is always the correct one. Of course, you can't put everything imaginable in. But things that are part of a general pattern are good candidates. Nobody could _ever_ design very useful code, if not following this principal. I once, in my very first job, had to rework a big test driver written in such a way that it handled exactly the set of test cases that had been originally specified and not a thing more. Nobody could add any new cases as things evolved. The internal structure bore no resemblance to the pattern of the inputs. I could only throw it all out except for some low-level routines and start over. > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by > m3middle, so let's support it and not get bitten in the arse if/when > m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or > right to left, I looked at these two examples and decided they can't > both be correct. > > - Jay > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > From jkrell at elego.de Thu Mar 4 23:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225038.01F032474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:50:37 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go a back a version to 1.88 From jkrell at elego.de Thu Mar 4 23:52:57 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:52:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225257.BA75F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:52:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: back to versoin 1.123 pending more testing From jay.krell at cornell.edu Fri Mar 5 01:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 00:50:28 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100304225257.BA75F2474001@birch.elegosoft.com> References: <20100304225257.BA75F2474001@birch.elegosoft.com> Message-ID: This was probably fine. I had a failure on a machine but that was possibly some uncommited version. I also had some version go through ok on LINUXLIBC6 and some version on AMD64_DARWIN so the approach is ok. To be certain I reverted it for now. Will probably back something within 24 hours. I'll maybe test SOLgnu and PPC_DARWIN as well. - Jay ---------------------------------------- > Date: Thu, 4 Mar 2010 23:52:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/04 23:52:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > back to versoin 1.123 pending more testing > From jkrell at elego.de Fri Mar 5 11:25:21 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 11:25:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305102521.7CBCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 11:25:21 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: small workaround wrt M3_PROFILING for older cm3 and/or other m3quake users other than cm3 From jkrell at elego.de Fri Mar 5 12:16:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:16:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305111649.CD4AF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:16:49 Modified files: cm3/scripts/python/: pylib.py Log message: don't put mklib in boot archives just because the overly simple makefile can only link one executable; don't include --32 on PPC_LINUX assembler invocations, it doesn't like it From jkrell at elego.de Fri Mar 5 12:56:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:56:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305115628.4F8B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:56:28 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC64_DARWIN Log message: 'PPC.common' => 'PPC64.common' From jkrell at elego.de Fri Mar 5 13:19:02 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:19:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305121902.4D7792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:19:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: #if __APPLE__ && __x86_64__ => __APPLE__ && __LP64__ so that is also works on PPC64 From jkrell at elego.de Fri Mar 5 13:45:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:45:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124527.D0EA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:45:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again: remove set_member and set_singleton From jkrell at elego.de Fri Mar 5 13:48:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:48:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124817.C66CB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:48:17 Modified files: cm3/scripts/python/: pylib.py Log message: add -arch ppc64 on PPC64_DARWIN, like -arch x86_64 on AMD64_DARWIN From jkrell at elego.de Fri Mar 5 13:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125132.72FE32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:51:32 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. The first two platforms fail to link due to references to these functions. Presumably the last too. I know the plan is to fallback to locks somewhere, but I don't think they have materialized yet. From jkrell at elego.de Fri Mar 5 13:53:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:53:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125358.707872474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:53:58 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. From jkrell at elego.de Fri Mar 5 13:54:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:54:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125444.8D6CE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:54:44 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadApple.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. (same problem and fix as RTSignalC.c) From jkrell at elego.de Fri Mar 5 13:57:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:57:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125712.A4F8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:57:12 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadInterix.c Log message: not used: ThreadInterix.c From jkrell at elego.de Fri Mar 5 14:09:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305130939.75E332474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:09:39 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: decrease PPC_DARWIN jmpbuf align to 32 add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:11:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:11:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131147.559DB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:11:47 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: slightly different style From jkrell at elego.de Fri Mar 5 14:16:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:16:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131629.36D552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:16:29 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131713.EB0262474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:17:13 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add PPC64_DARWIN (only needed for cross builds I believe, but that's what I did so far) From jay.krell at cornell.edu Fri Mar 5 14:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 13:57:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4B901BD8.10403@lcwb.coop> References: <20100303092142.7B7862474001@birch.elegosoft.com>, ,,, , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I understand that. I often am "like that". But we are our own consumers. The code has probably been unused a long time, but I didn't check. We can put it in when we need it. http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it - Jay > Date: Thu, 4 Mar 2010 14:45:12 -0600 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay K wrote: > > Maybe remove it instead? Unused suggests untested, not working. > > I am with Tony on this one. Well-designed code has always had places where > it will handle a more general input space than current use-cases demand. > > Always removing everything from what is handled reflects the view that a > program is a one-time thing that never changes. Putting in some things > that follow a consistent general pattern reflects the view that a program > is an evolving thing. Excepting a very few programs that are either trivial > or very little-used, the latter assumption is always the correct one. > > Of course, you can't put everything imaginable in. But things that are part > of a general pattern are good candidates. Nobody could _ever_ design very > useful code, if not following this principal. > > I once, in my very first job, had to rework a big test driver written in > such a way that it handled exactly the set of test cases that had been > originally specified and not a thing more. Nobody could add any new cases > as things evolved. The internal structure bore no resemblance to the > pattern of the inputs. I could only throw it all out except for some > low-level routines and start over. > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > It turns out not actually to be used by m3front. But it is defined by > > m3middle, so let's support it and not get bitten in the arse if/when > > m3front ever uses it. > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > I don't see where it is used. > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > (in m3back). > > The parameters are being passed to memset in the wrong order. > > Compare it to m3cg_zero. > > I was actually looking to see if parameters are left to right or > > right to left, I looked at these two examples and decided they can't > > both be correct. > > > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > To: hosking at cs.purdue.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Please say how this is broken. > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > Huh? I see it in the front-end! > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 15:12:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:12:55 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305125132.72FE32474001@birch.elegosoft.com> References: <20100305125132.72FE32474001@birch.elegosoft.com> Message-ID: I think PPC has the necessary instructions. Does gcc not generate them? Maybe need a -arch parameter to get it to use them. On 5 Mar 2010, at 13:51, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/05 13:51:32 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > > Log message: > Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. > The first two platforms fail to link due to references to these > functions. Presumably the last too. I know the plan is to fallback to > locks somewhere, but I don't think they have materialized yet. From hosking at elego.de Fri Mar 5 15:16:38 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 5 Mar 2010 15:16:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305141638.827582474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/05 15:16:38 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: Cleaner! From hosking at cs.purdue.edu Fri Mar 5 15:17:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:17:21 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I already fixed it! On 5 Mar 2010, at 08:57, Jay K wrote: > I understand that. I often am "like that". > But we are our own consumers. The code has probably been unused a long time, but I didn't check. > We can put it in when we need it. > http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it > > > - Jay > > > > Date: Thu, 4 Mar 2010 14:45:12 -0600 > > From: rodney_bates at lcwb.coop > > To: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > Jay K wrote: > > > Maybe remove it instead? Unused suggests untested, not working. > > > > I am with Tony on this one. Well-designed code has always had places where > > it will handle a more general input space than current use-cases demand. > > > > Always removing everything from what is handled reflects the view that a > > program is a one-time thing that never changes. Putting in some things > > that follow a consistent general pattern reflects the view that a program > > is an evolving thing. Excepting a very few programs that are either trivial > > or very little-used, the latter assumption is always the correct one. > > > > Of course, you can't put everything imaginable in. But things that are part > > of a general pattern are good candidates. Nobody could _ever_ design very > > useful code, if not following this principal. > > > > I once, in my very first job, had to rework a big test driver written in > > such a way that it handled exactly the set of test cases that had been > > originally specified and not a thing more. Nobody could add any new cases > > as things evolved. The internal structure bore no resemblance to the > > pattern of the inputs. I could only throw it all out except for some > > low-level routines and start over. > > > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > It turns out not actually to be used by m3front. But it is defined by > > > m3middle, so let's support it and not get bitten in the arse if/when > > > m3front ever uses it. > > > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > > > I don't see where it is used. > > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > > (in m3back). > > > The parameters are being passed to memset in the wrong order. > > > Compare it to m3cg_zero. > > > I was actually looking to see if parameters are left to right or > > > right to left, I looked at these two examples and decided they can't > > > both be correct. > > > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > > To: hosking at cs.purdue.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Please say how this is broken. > > > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > > > Huh? I see it in the front-end! > > > > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 15:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305143429.4B9522474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:34:29 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: oops I was fiddling with bytes and bits and how to annotate them and I got it wrong: alignment is 32, 32 bits From jkrell at elego.de Fri Mar 5 15:46:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305144640.E147F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:46:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: no ODBC on PPC64_DARWIN From jkrell at elego.de Fri Mar 5 15:51:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:51:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305145148.851592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:51:47 Modified files: cm3/scripts/python/: pylib.py Log message: detect PPC64_DARWIN, from 32bit Python, by comparing ppc970 to ppc970 From jkrell at elego.de Fri Mar 5 16:00:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:00:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150035.B69F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:00:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: PPC64_DARWIN 10.4: no X, no Trestle: we need to teach cm3 to sniff the directories/files and their architectures From jkrell at elego.de Fri Mar 5 16:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150658.81EB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:06:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:09:19 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:09:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150919.85D9E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:09:19 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:16:15 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:16:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305151615.2DEEA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:16:15 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: fix typo, so it works on big endian systems, such as PPC64_DARWIN (and PPC_DARWIN, PPC_LINUX, SOLgnu, SPARC32_LINUX, etc.) From jkrell at elego.de Fri Mar 5 16:22:06 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:22:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152206.117CC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:22:06 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: replace portable output with correct output From jkrell at elego.de Fri Mar 5 16:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152514.247902474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:25:14 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm32 stdout.pgm64 Removed files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian32 stdout.pgm-little_endian64 Log message: it turns out this isn't (currently) endian specific, just wordsize specific (PPC64_DARWIN output matches AMD64_DARWIN) From jay.krell at cornell.edu Fri Mar 5 16:32:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 15:32:00 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305141638.827582474001@birch.elegosoft.com> References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear I suppose for alignment I could say bits = 1. - Jay > Date: Fri, 5 Mar 2010 15:16:38 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/05 15:16:38 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > Cleaner! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 17:11:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 11:11:41 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: <343D34B0-D380-4FEF-AD8B-B2DB03E6A8F3@cs.purdue.edu> Why not multiply by some appropriate size. x * Int32.size, etc.? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Mar 2010, at 10:32, Jay K wrote: > sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear > I suppose for alignment I could say bits = 1. > > - Jay > > > > Date: Fri, 5 Mar 2010 15:16:38 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/05 15:16:38 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > Log message: > > Cleaner! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 22:11:26 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:11:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211126.9928B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:11:26 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: do it the usual way: * Word8.size; Word32.size From jkrell at elego.de Fri Mar 5 22:17:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:17:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211729.31D422474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:17:29 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertToCygwinPath' => 'ConvertToCygwinPath' (private to public) so that make-dist.py works From jkrell at elego.de Fri Mar 5 22:18:48 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:18:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211848.6ABD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:18:48 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertFromCygwinPath' => 'ConvertFromCygwinPath' (private to public) just to match ConvertToCygwinPath (not used) From jkrell at elego.de Sat Mar 6 12:02:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:02:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306110201.94DED2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:02:01 Added files: cm3/m3-sys/m3tests/src/p2/p231/: m3makefile Main.m3 Log message: small test case split out of p227 that shows something m3back currently fails to compile From jkrell at elego.de Sat Mar 6 12:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306111830.94AB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:18:30 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm Log message: big endian output (and really we have to compare this with an older compiler, make sure replacement of set_singleton hasn't changed which bits are set -- pickle compatibility) From jkrell at elego.de Sat Mar 6 12:23:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:23:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112338.8F4482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:23:38 Removed files: cm3/m3-sys/m3tests/src/p2/p225/: stderr.build stdout.build stderr.pgm Log message: shouldn't need the zero sized files any longer From jkrell at elego.de Sat Mar 6 12:26:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:26:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112629.ED4102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:26:29 Modified files: cm3/m3-sys/m3tests/src/p2/p231/: Main.m3 Log message: comment as to what the test is for From jkrell at elego.de Sat Mar 6 13:38:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306123838.6C3B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:38:38 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: some cleanup ahead of other fixes (the free_temp problem) in particular: - replace RegSet{} with AllRegisters This makes some code a little simpler. RegSet{} does mean "anything" and we can capture that pretty faithfully via AllRegisters. We are lucky we don't have to allocate float registers though, that might call for something a little different - in some places I was extra cautious and ran the same old code for size = 1 (data fitting in a single register), as well there are places that assume the largest size is 2 Generalize *some* of that to loop over whatever size, doing the "same" thing at each step. There are still places that say like "if foo[0] and foo[size - 1]" which works as long as size can only be 1 or 2. - fix warning about unreachable code after assert false (the unused, untested zero_n) From jay.krell at cornell.edu Sat Mar 6 13:39:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:39:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306123838.6C3B22474001@birch.elegosoft.com> References: <20100306123838.6C3B22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 6 Mar 2010 13:38:38 +0000 > To: m3commit > From: jkrell > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:38:38 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > some cleanup ahead of other fixes (the free_temp problem) > > in particular: > - replace RegSet{} with AllRegisters > This makes some code a little simpler. > RegSet{} does mean "anything" and we can > capture that pretty faithfully via AllRegisters. > We are lucky we don't have to allocate float registers though, > that might call for something a little different > > - in some places I was extra cautious and ran > the same old code for size = 1 (data fitting in a single register), > as well there are places that assume the largest size is 2 > Generalize *some* of that to loop over whatever size, doing > the "same" thing at each step. > > There are still places that say like "if foo[0] and foo[size - 1]" > which works as long as size can only be 1 or 2. > > - fix warning about unreachable code after assert false (the unused, > untested zero_n) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 6 13:55:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306125552.552592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:55:52 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 only call free_temp for operandPart = 0 Better might be to, like, remove some/many of the loops and teach more of the code to deal with "multi part operands" (or multi register operands). From jay.krell at cornell.edu Sat Mar 6 13:56:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:56:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306125552.552592474001@birch.elegosoft.com> References: <20100306125552.552592474001@birch.elegosoft.com> Message-ID: very small diff inline: Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.112 diff -u -r1.112 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:38:38 -0000 1.112 +++ Stackx86.m3 6 Mar 2010 12:54:37 -0000 @@ -197,7 +197,9 @@ IF op.loc = OLoc.mem THEN IF op.mvar.var.stack_temp THEN - t.parent.free_temp(op.mvar.var); + IF operandPart = 0 THEN + t.parent.free_temp(op.mvar.var); + END; ELSE t.reguse[r].last_store := op.mvar; END > Date: Sat, 6 Mar 2010 13:55:52 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:55:52 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 > only call free_temp for operandPart = 0 > > Better might be to, like, remove some/many of the loops and > teach more of the code to deal with "multi part operands" > (or multi register operands). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 7 03:32:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:32:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023243.806FA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:32:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: 'ulong' => 'size_t' where it is easy (more coming) From jkrell at elego.de Sun Mar 7 03:33:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:33:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023327.12FAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:33:26 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove check for older Microsoft compiler with no __int64 support (16bit compiler) From jkrell at elego.de Sun Mar 7 03:34:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:34:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023450.6F4212474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:34:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: assume but verify that uint is 32bits From jkrell at elego.de Sun Mar 7 03:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023531.EEFAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:35:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add comment From jkrell at elego.de Sun Mar 7 03:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023704.88E182474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:37:04 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: maybe a safer check, in case of overflow From jkrell at elego.de Sun Mar 7 03:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307024743.D13762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:47:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: this part of the test is 32bit specific From jkrell at elego.de Sun Mar 7 03:54:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:54:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307025406.5C6C92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:54:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'ulong' => 'size_t' (much of this going away shortly) From jkrell at elego.de Sun Mar 7 04:01:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:01:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030112.BA0DA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:01:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'size_t' => 'ulong' to fix gcc printf warnings From jkrell at elego.de Sun Mar 7 04:06:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:06:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030630.9093B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:06:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: collect timings on other platforms, albeit low resolution From jkrell at elego.de Sun Mar 7 04:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032021.E1DFF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:20:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: replace set_range with set_range_new set_range_new is never significantly slower and sometimes significantly faster, depending on architecture, compiler, optimization flags optimization definitely helps this code a lot sometimes, e.g. old is 9 seconds unoptimized on sparc64, new is 3 seconds unoptimized they are both 26 seconds we should probably use #pragmas to ensure it is optimized Still have NT386 tables, to be removed soon. From jkrell at elego.de Sun Mar 7 04:21:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:21:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032148.A06B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:21:47 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ulong typedef is unused now, remove it From jkrell at elego.de Sun Mar 7 04:24:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:24:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032420.9D4112474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:24:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove all the "not yet" stuff I put in recently: math with overflow checking I still think we might do something like this, though we can probably write it just as well in Modula-3, if not get the compiler to give us the carry flag (certainly m3back can do better) Anyway, we can recover it from here if needed. From jay.krell at cornell.edu Sun Mar 7 04:24:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:24:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032420.9D4112474001@birch.elegosoft.com> References: <20100307032420.9D4112474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:24:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:24:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > remove all the "not yet" stuff I put in recently: math with overflow checking > I still think we might do something like this, though > we can probably write it just as well in Modula-3, > if not get the compiler to give us the carry flag (certainly > m3back can do better) > Anyway, we can recover it from here if needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:26:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032619.2B77B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:26:19 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: again remove set_member and set_singleton: neither backend references them any longer From jkrell at elego.de Sun Mar 7 04:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032706.2E8CD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:27:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove #define of __fastcall, unused From jkrell at elego.de Sun Mar 7 04:28:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:28:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032816.7237A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:28:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put _lowbits, _highbits under #ifdef _WIN32; m3back uses them for insert/extract; they will go away soon anyway From jay.krell at cornell.edu Sun Mar 7 04:20:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:20:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032021.E1DFF2474001@birch.elegosoft.com> References: <20100307032021.E1DFF2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:20:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:20:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c > > Log message: > replace set_range with set_range_new > set_range_new is never significantly slower and sometimes significantly faster, > depending on architecture, compiler, optimization flags > optimization definitely helps this code a lot sometimes, e.g. > old is 9 seconds unoptimized on sparc64, new is 3 seconds > unoptimized they are both 26 seconds > we should probably use #pragmas to ensure it is optimized > > Still have NT386 tables, to be removed soon. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:32:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033246.0A6542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:32:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the old div and mod functions put the current 64bit div and mod under #ifdef _WIN32 gcc backend no longer references any div/mod functions and m3back only does so for 64bit longint (at least for now) From jkrell at elego.de Sun Mar 7 04:33:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:33:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033348.D46452474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:33:48 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove very old 'crash' function that has been sitting here commented out for years From jkrell at elego.de Sun Mar 7 04:35:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:35:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033535.3006B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:35:34 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define WIN32_STATIC From jkrell at elego.de Sun Mar 7 04:36:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033619.C8A202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define INT64_MIN, INT64_MAX, they probably went with the math with overflow checking functions From jkrell at elego.de Sun Mar 7 04:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033651.042102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: oops: the new set_range must not be static From jkrell at elego.de Sun Mar 7 04:49:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:49:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307034944.02C542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:49:43 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove whitespace from ends of lines From jkrell at elego.de Sun Mar 7 04:50:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307035015.D283F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:50:15 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: restore INT64_MIN, INT64_MAX (test code only) From jkrell at elego.de Sun Mar 7 05:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307043751.99BB92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:37:51 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: demonstrate the formula m3back uses for more efficient bit extraction it is x86 specific in that shift counts are treated mod 32 and it doesn't work for extracting zero bits, we should check that we are never asked for that From jkrell at elego.de Sun Mar 7 05:45:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:45:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307044521.881992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:45:21 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: don't allow extracting and sign extending zero bits From jay.krell at cornell.edu Sun Mar 7 05:46:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 04:46:05 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307044521.881992474001@birch.elegosoft.com> References: <20100307044521.881992474001@birch.elegosoft.com> Message-ID: small diff attached/inline Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.113 diff -u -r1.113 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:55:52 -0000 1.113 +++ Stackx86.m3 7 Mar 2010 04:42:39 -0000 @@ -1641,6 +1641,15 @@ really messy to cover all the special cases correctly *) IF sign THEN + + (* The method used here does not work for extracting zero bits. + * Make sure we are not asked to do that. + *) + IF NOT (stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero)) THEN + t.Err("doextract: not able to extract and sign extend zero bits"); + END; + <* ASSERT stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero) *> + find(t, stack0, Force.regset, RegSet { ECX }); find(t, stack1, Force.any); find(t, stack2, Force.anyreg); > Date: Sun, 7 Mar 2010 05:45:21 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 05:45:21 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > don't allow extracting and sign extending zero bits > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 07:38:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307063812.61BC82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:38:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put back assertions, until I verify there are separate runtime checks; put uint32 check and typedef next to each other From jkrell at elego.de Sun Mar 7 07:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064053.7CE822474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:40:53 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: move #define I64 from hand.c to test_hand.c From jkrell at elego.de Sun Mar 7 07:47:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:47:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064702.607B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:47:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the insert/extract64 functions from non-Windows builds From jkrell at elego.de Sun Mar 7 07:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064855.0D38C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:48:54 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix indentation of set_range From jkrell at elego.de Sun Mar 7 07:49:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:49:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064932.6667C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:49:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ~0UL => ~(size_t)0 From jkrell at elego.de Sun Mar 7 08:09:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 8:09:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307070937.AF9B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 08:09:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 Log message: put ASSERT FALSE after every error Also this way I don't have to repeat every condition. From jay.krell at cornell.edu Sun Mar 7 08:10:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 07:10:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307070937.AF9B92474001@birch.elegosoft.com> References: <20100307070937.AF9B92474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 08:09:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 08:09:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 > > Log message: > put ASSERT FALSE after every error > Also this way I don't have to repeat every condition. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 09:31:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 9:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307083125.E71382474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 09:31:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: make procedure find a little more conservative with regard to the 64bit longint changes in particular, don't change the 'set' variable, instead: - in[i] := inreg(t, opA[i].mvar, set); - IF size > 1 THEN - set := set - RegSet{in[i]}; + IF i = 0 THEN + in[i] := inreg(t, opA[i].mvar, set); + ELSE + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); END; (though I was hoping to remove the assumption that size <= 2, I have increased) put procedure pushnew1 and procedure pushnew back together as one procedure, with loops inside it it kind of looks like otherwise might have e.g. saved stuff to two temporary variables instead of one rename procedure maybe_expand_stack to expand_stack it still only expands the stack sometimes, but I think the name is adequate eliminate unnecessary variable 'size' in procedure discard some whitespace/commenting changes From jay.krell at cornell.edu Sun Mar 7 09:38:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 08:38:07 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307083125.E71382474001@birch.elegosoft.com> References: <20100307083125.E71382474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 09:31:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 09:31:25 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > make procedure find a little more conservative > with regard to the 64bit longint changes > in particular, don't change the 'set' variable, > instead: > > - in[i] := inreg(t, opA[i].mvar, set); > - IF size > 1 THEN > - set := set - RegSet{in[i]}; > + IF i = 0 THEN > + in[i] := inreg(t, opA[i].mvar, set); > + ELSE > + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); > END; > > (though I was hoping to remove the assumption that size <= 2, I have increased) > > put procedure pushnew1 and procedure pushnew back together as > one procedure, with loops inside it > it kind of looks like otherwise might have e.g. saved stuff to two temporary variables > instead of one > > rename procedure maybe_expand_stack to expand_stack > it still only expands the stack sometimes, but I think the name is adequate > > eliminate unnecessary variable 'size' in procedure discard > > some whitespace/commenting changes > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 10:15:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:15:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091540.25EEF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:15:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091840.E254B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:40 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091854.484B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 12:11:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 12:11:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307111154.C02122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 12:11:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: correct and increase restrictions on extract parameters n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) if sign_extend, then must be constant and > 1 There is historical code for dealing with non-constant n and sign extension, and it is apparently clever and correct, except it doesn't work for n = 0. If we need this to work better, we could insert a runtime check for n = 0, or use code that handles 0 (see hand.c, at least for now). Word/Long do not expose extract with sign extension. The option is available only to m3back clients, ie. m3front, and it's not hard to imagine that the number of bits it wants is always constant and never 0. From jay.krell at cornell.edu Sun Mar 7 12:16:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 11:16:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307111154.C02122474001@birch.elegosoft.com> References: <20100307111154.C02122474001@birch.elegosoft.com> Message-ID: attached > Date: Sun, 7 Mar 2010 12:11:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 12:11:54 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > correct and increase restrictions on extract parameters > n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) > if sign_extend, then must be constant and > 1 > > There is historical code for dealing with non-constant n and sign extension, > and it is apparently clever and correct, except it doesn't work for n = 0. > If we need this to work better, we could insert a runtime check for n = 0, > or use code that handles 0 (see hand.c, at least for now). > > Word/Long do not expose extract with sign extension. > The option is available only to m3back clients, ie. m3front, > and it's not hard to imagine that the number of bits it wants > is always constant and never 0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307120326.C3A742474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:03:26 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove commented out code regarding bin_use and lib_use (which don't exist) From jkrell at elego.de Sun Mar 7 13:13:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:13:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307121318.8535A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:13:18 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: make -no-m3ship-resolution work in more circumstances, such as when environment variable CM3_INSTALL has forward slashes, on Windows. Note that we now break -no-m3ship-resolution in the unusual case of a Posix user using \ as a "normal" path character. I consider that highly unlikely, however if needed, there are other solutions here. From jay.krell at cornell.edu Sun Mar 7 13:14:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 12:14:08 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307121318.8535A2474001@birch.elegosoft.com> References: <20100307121318.8535A2474001@birch.elegosoft.com> Message-ID: diff attached - Jay > Date: Sun, 7 Mar 2010 13:13:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 13:13:18 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > make -no-m3ship-resolution work in more circumstances, such > as when environment variable CM3_INSTALL has forward slashes, > on Windows. > Note that we now break -no-m3ship-resolution in the unusual > case of a Posix user using \ as a "normal" path character. > I consider that highly unlikely, however if needed, there > are other solutions here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307123914.717A22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:39:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> after ever Err() I thought I had already done this, but I missed a bunch. This way we get a callstack. From jkrell at elego.de Sun Mar 7 13:44:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:44:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307124411.AB5D52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:44:11 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: wordsmithing/comments: in particular, make it completely obvious to any quick observer which code is commented out, by putting * at the start of every line From jkrell at elego.de Sun Mar 7 15:12:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:12:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141218.728F62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! From jkrell at elego.de Sun Mar 7 15:17:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:17:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141745.C5E312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:17:45 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 Log message: further narrow down extract to what m3front uses and we can therefore test => sign_extend requires constant m and constant n (I'm thinking I should see if the coverage stuff works.. and if not fix it..) stack should handle all 32bit cases inline leaving the function calls only for some 64bit cases (for now) something is fishy here for 64bit + sign extension + non constant m/n will resolve shortly (for now I'm leaving 64bit extract + sign extend + non constant m/n) some newlines for readability From jay.krell at cornell.edu Sun Mar 7 15:18:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 14:18:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141745.C5E312474001@birch.elegosoft.com> References: <20100307141745.C5E312474001@birch.elegosoft.com> Message-ID: diff attached.. > Date: Sun, 7 Mar 2010 15:17:45 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:17:45 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 > > Log message: > further narrow down extract to what m3front uses > and we can therefore test > => sign_extend requires constant m and constant n > (I'm thinking I should see if the coverage stuff works.. > and if not fix it..) > > stack should handle all 32bit cases inline > leaving the function calls only for some 64bit cases (for now) > > something is fishy here for 64bit + sign extension + non constant m/n > will resolve shortly > (for now I'm leaving 64bit extract + sign extend + non constant m/n) > > some newlines for readability > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From hosking at cs.purdue.edu Sun Mar 7 17:03:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Mar 2010 11:03:51 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141218.728F62474001@birch.elegosoft.com> References: <20100307141218.728F62474001@birch.elegosoft.com> Message-ID: That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:12:18 > > Modified files: > cm3/m3-sys/m3front/src/builtinOps/: Number.m3 > > Log message: > Fix test p078. > Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it > easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Sun Mar 7 17:08:50 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 7 Mar 2010 17:08:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307160850.E8CB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/07 17:08:50 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Let's just preserve the historical sense of things for easier diffing from prehistory. [Jay, yes I know that you think it is easier to read without the logical negations, but I want to have something that avoids gratuitous changes in the record that make diffing with past versions noisier than necessary.] From jay.krell at cornell.edu Sun Mar 7 23:29:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 22:29:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100307141218.728F62474001@birch.elegosoft.com>, Message-ID: Imagine you were writing a bounds check with INTEGER. Would you write: a, min, max: INTEGER; IF a >= min AND a <= max reasonable IF min <= a AND a <= max reasonable IF NOT a < min AND NOT max < a seems kind of contorted? but ok. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Mar 2010 11:03:51 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 05:28:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308042831.4D0652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:28:31 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more 64bit division tests From jkrell at elego.de Mon Mar 8 05:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044736.39EF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:47:36 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more division tests, in particular of constants that don't fit in 32bits and that are powers of 2 From jkrell at elego.de Mon Mar 8 05:48:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:48:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044802.9DFD22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:48:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: inline 64bit sign extending extracts (constant m/n) actually related to sign extending 64bit right shift it depends on that for the implementation actually related to 64bit division with constants, since the frontend converts some of them to 64bit extract_mn (see test p227) From jay.krell at cornell.edu Mon Mar 8 05:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 04:48:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308044802.9DFD22474001@birch.elegosoft.com> References: <20100308044802.9DFD22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 05:48:02 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 05:48:02 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > inline 64bit sign extending extracts (constant m/n) > actually related to sign extending 64bit right shift > it depends on that for the implementation > actually related to 64bit division with constants, since > the frontend converts some of them to 64bit extract_mn (see test p227) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Mon Mar 8 05:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308045713.865762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:57:13 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove support for 64bit sign extending extract the backend inlines them all now (they always have constant m and n) From jkrell at elego.de Mon Mar 8 06:08:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 6:08:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308050802.414FB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 06:08:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove asserts from insert/extract, runtime checks are already done before this From jkrell at elego.de Mon Mar 8 10:41:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:41:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094115.6FFD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:41:15 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: fix last minute edits From jkrell at elego.de Mon Mar 8 10:45:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:45:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094503.7B0842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:45:03 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: perhaps cleaner to call the '1' functions less and the 'normal' functions more, only calling 'foo1' from 'foo' and nowhere else From jkrell at elego.de Mon Mar 8 13:26:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 13:26:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308122636.83CA12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 13:26:36 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" extract to not use tables and always be inlined for 64bit equivalent C code: UT __stdcall extract(UT x, uint32 offset, uint32 count) { x >>= offset; x &= ~((~(UT)0) << count); return x; } extract32 00000729: 8B4DEC MOV ECX tv.126[_m] 0000072C: 8B5DF4 MOV EBX tv.124[_a32] 0000072F: D3EB SHR EBX 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. 00000733: 8B4DE4 MOV ECX tv.128[_n] 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? 0000073B: D3E6 SHL ESI 0000073D: F7D6 NOT ESI 0000073F: 23DE AND EBX ESI extract64 000008E4: 8B4DD8 MOV ECX tv.134[_m] 000008E7: 8B5DE8 MOV EBX tv.131[_a64] 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 000008ED: 0FADD3 SHRD EBX EDX ECX 000008F0: D3EA SHR EDX 000008F2: F6C120 TEST ECX $32 000008F5: 7400 JE rel8 L.107 000008F7: 8BDA MOV EBX EDX 000008F9: 33D2 XOR EDX EDX set_label L.107 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. 000008FD: 8B4DD0 MOV ECX tv.136[_n] 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) 0000090A: 0FA5F8 SHLD EAX EDI ECX 0000090D: D3E7 SHL EDI 0000090F: F6C120 TEST ECX $32 00000912: 7400 JE rel8 L.108 00000914: 8BC7 MOV EAX EDI 00000916: 33FF XOR EDI EDI set_label L.108 00000918: F7D7 NOT EDI 0000091A: F7D0 NOT EAX 0000091C: 23DF AND EBX EDI 0000091E: 23D0 AND EDX EAX having n or m and n (or just m? I think so.) be constant leads to better code some other small cleanup, like avoiding calling find twice, I don't see why it was that way From jay.krell at cornell.edu Mon Mar 8 13:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 12:30:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308122636.83CA12474001@birch.elegosoft.com> References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308130650.47BA72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:06:50 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a lot of renaming for a lot more readability n => count m => offset consider that have functions insert, insert_n, insert_mn extract, extract_n, extract_mn it gets confusing and then more so, stack0 => stack_offset, stack_count, etc. stop0 => op_offset, op_count, etc. It's even worse there. Functions with so many parameters should use names, not stack offsets. From jay.krell at cornell.edu Mon Mar 8 14:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308130650.47BA72474001@birch.elegosoft.com> References: <20100308130650.47BA72474001@birch.elegosoft.com> Message-ID: diff attached it's a lot of churn but the result is much easier to read - Jay > Date: Mon, 8 Mar 2010 14:06:50 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:06:50 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a lot of renaming for a lot more readability > n => count > m => offset > > consider that have functions > insert, insert_n, insert_mn > extract, extract_n, extract_mn > > it gets confusing > > and then more so, > > stack0 => stack_offset, stack_count, etc. > stop0 => op_offset, op_count, etc. > > It's even worse there. Functions with > so many parameters should use names, not stack offsets. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:18:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:18:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308131806.6019F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:18:06 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little bit of cleanup and dead code removal including: another numbered to named variable sign_extending extract without constant offset/count From jay.krell at cornell.edu Mon Mar 8 14:18:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:18:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308131806.6019F2474001@birch.elegosoft.com> References: <20100308131806.6019F2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 14:18:06 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:18:06 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a little bit of cleanup and dead code removal > including: > another numbered to named variable > sign_extending extract without constant offset/count > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135335.0184A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:53:34 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: It helps to split TestInsert/TestExtract into TestInsert32/TestInsert64/TestExtract32/TestExtract64 because the backend reuses temporary variables and their names end up confusing, if you read the debug output. From jkrell at elego.de Mon Mar 8 14:54:10 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:54:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135410.663152474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:54:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: remove sign_extend, it was always 0 From jkrell at elego.de Mon Mar 8 14:59:26 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:59:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135926.D46412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:59:26 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm32 stdout.pgm64 Log message: update output: from LINUXLIBC6 and AMD64_DARWIN From hosking at cs.purdue.edu Mon Mar 8 16:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 8 Mar 2010 10:29:00 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/08 13:26:36 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > > > Log message: > > "rewrite" extract to not use tables and always be inlined for 64bit > > > > equivalent C code: > > > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > > { > > x >>= offset; > > x &= ~((~(UT)0) << count); > > return x; > > } > > > > extract32 > > 00000729: 8B4DEC MOV ECX tv.126[_m] > > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > > 0000072F: D3EB SHR EBX > > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > > 00000733: 8B4DE4 MOV ECX tv.128[_n] > > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > > 0000073B: D3E6 SHL ESI > > 0000073D: F7D6 NOT ESI > > 0000073F: 23DE AND EBX ESI > > > > extract64 > > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > > 000008ED: 0FADD3 SHRD EBX EDX ECX > > 000008F0: D3EA SHR EDX > > 000008F2: F6C120 TEST ECX $32 > > 000008F5: 7400 JE rel8 L.107 > > 000008F7: 8BDA MOV EBX EDX > > 000008F9: 33D2 XOR EDX EDX > > set_label L.107 > > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > > 0000090A: 0FA5F8 SHLD EAX EDI ECX > > 0000090D: D3E7 SHL EDI > > 0000090F: F6C120 TEST ECX $32 > > 00000912: 7400 JE rel8 L.108 > > 00000914: 8BC7 MOV EAX EDI > > 00000916: 33FF XOR EDI EDI > > set_label L.108 > > 00000918: F7D7 NOT EDI > > 0000091A: F7D0 NOT EAX > > 0000091C: 23DF AND EBX EDI > > 0000091E: 23D0 AND EDX EAX > > > > having n or m and n (or just m? I think so.) be constant leads to better code > > > > some other small cleanup, like avoiding calling find twice, > > I don't see why it was that way > > > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 17:03:48 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308160348.F40EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:03:48 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" insert to not use tables and to inline 64bit operations It is modeled after: T insert(T to, T from, uint32 offset, uint32 count) { T mask = ((~((~(T)0) << count)) << offset); return (to & ~mask) | ((from << offset) & mask); } I spent some time trying to remove the unnecessary instructions. No luck yet. The problem is the codegen wants to preserve offset/count after we are done with them. The usage of the constant "-1" will be optimized later. Constant offset and count should generate much better code. Just constant offset or count, not much different (shift immediate instead of shift by ecx). er, actually the shifts might be significantly optimized. Calculation of the mask ought to be better just for constant count, to be looked at later. It may be profitable to come up with other formulas. These at least are "branch free" (except for the branches within the shifts). The basic general patterns are, which you can see follow the C code closely: insert Word.32 00000226: 8B4DD0 MOV ECX tv.103[_n] 00000229: BEFFFFFFFF MOV ESI $4294967295 0000022E: D3E6 SHL ESI 00000230: F7D6 NOT ESI 00000232: 8BF9 MOV EDI ECX This isn't needed! 00000234: 8B4DD8 MOV ECX tv.101[_m] 00000237: D3E6 SHL ESI 00000239: D3E2 SHL EDX 0000023B: 23D6 AND EDX ESI 0000023D: F7D6 NOT ESI 0000023F: 23DE AND EBX ESI 00000241: 0BDA OR EBX EDX insert Word.64 000004EB: 8B4DB0 MOV ECX tv.117[_n] 000004EE: BBFFFFFFFF MOV EBX $4294967295 000004F3: BEFFFFFFFF MOV ESI $4294967295 000004F8: 0FA5DE SHLD ESI EBX ECX 000004FB: D3E3 SHL EBX 000004FD: F6C120 TEST ECX $32 00000500: 7400 JE rel8 L.75 00000502: 8BF3 MOV ESI EBX 00000504: 33DB XOR EBX EBX set_label L.75 00000506: F7D3 NOT EBX 00000508: F7D6 NOT ESI 0000050A: 8BF9 MOV EDI ECX 0000050C: 8B4DB8 MOV ECX tv.115[_m] 0000050F: 0FA5DE SHLD ESI EBX ECX 00000512: D3E3 SHL EBX 00000514: F6C120 TEST ECX $32 00000517: 7400 JE rel8 L.76 00000519: 8BF3 MOV ESI EBX 0000051B: 33DB XOR EBX EBX set_label L.76 0000051D: 0FA5C2 SHLD EDX EAX ECX 00000520: D3E0 SHL EAX 00000522: F6C120 TEST ECX $32 00000525: 7400 JE rel8 L.77 00000527: 8BD0 MOV EDX EAX 00000529: 33C0 XOR EAX EAX set_label L.77 0000052B: 23C3 AND EAX EBX 0000052D: 23D6 AND EDX ESI 0000052F: F7D3 NOT EBX 00000531: F7D6 NOT ESI declare_temp 4 4 Int.32 F tv.119[T$119] -88 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! 00000536: 8B7DE8 MOV EDI tv.108[_a64] declare_temp 4 4 Int.32 F tv.120[T$120] -92 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 0000053F: 23FB AND EDI EBX 00000541: 23CE AND ECX ESI 00000543: 0BF8 OR EDI EAX 00000545: 0BCA OR ECX EDX free_temp tv.120[T$120] free_temp tv.119[T$119] From jay.krell at cornell.edu Mon Mar 8 17:04:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:04:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , Message-ID: Fair enough. - Jay From: hosking at cs.purdue.edu Date: Mon, 8 Mar 2010 10:29:00 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 8 17:18:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:18:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308160348.F40EB2474001@birch.elegosoft.com> References: <20100308160348.F40EB2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 17:03:48 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 17:03:48 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" insert to not use tables and to inline 64bit operations > > It is modeled after: > > T insert(T to, T from, uint32 offset, uint32 count) > { > T mask = ((~((~(T)0) << count)) << offset); > return (to & ~mask) | ((from << offset) & mask); > } > > I spent some time trying to remove the unnecessary instructions. > No luck yet. The problem is the codegen wants to preserve offset/count > after we are done with them. > > The usage of the constant "-1" will be optimized later. > > Constant offset and count should generate much better code. > Just constant offset or count, not much different (shift immediate instead of shift by ecx). > er, actually the shifts might be significantly optimized. > Calculation of the mask ought to be better just for constant count, to be looked at later. > > It may be profitable to come up with other formulas. > These at least are "branch free" (except for the branches within the shifts). > > The basic general patterns are, which you can see follow the C code closely: > > insert Word.32 > 00000226: 8B4DD0 MOV ECX tv.103[_n] > 00000229: BEFFFFFFFF MOV ESI $4294967295 > 0000022E: D3E6 SHL ESI > 00000230: F7D6 NOT ESI > 00000232: 8BF9 MOV EDI ECX This isn't needed! > 00000234: 8B4DD8 MOV ECX tv.101[_m] > 00000237: D3E6 SHL ESI > 00000239: D3E2 SHL EDX > 0000023B: 23D6 AND EDX ESI > 0000023D: F7D6 NOT ESI > 0000023F: 23DE AND EBX ESI > 00000241: 0BDA OR EBX EDX > > insert Word.64 > 000004EB: 8B4DB0 MOV ECX tv.117[_n] > 000004EE: BBFFFFFFFF MOV EBX $4294967295 > 000004F3: BEFFFFFFFF MOV ESI $4294967295 > 000004F8: 0FA5DE SHLD ESI EBX ECX > 000004FB: D3E3 SHL EBX > 000004FD: F6C120 TEST ECX $32 > 00000500: 7400 JE rel8 L.75 > 00000502: 8BF3 MOV ESI EBX > 00000504: 33DB XOR EBX EBX > set_label L.75 > 00000506: F7D3 NOT EBX > 00000508: F7D6 NOT ESI > 0000050A: 8BF9 MOV EDI ECX > 0000050C: 8B4DB8 MOV ECX tv.115[_m] > 0000050F: 0FA5DE SHLD ESI EBX ECX > 00000512: D3E3 SHL EBX > 00000514: F6C120 TEST ECX $32 > 00000517: 7400 JE rel8 L.76 > 00000519: 8BF3 MOV ESI EBX > 0000051B: 33DB XOR EBX EBX > set_label L.76 > 0000051D: 0FA5C2 SHLD EDX EAX ECX > 00000520: D3E0 SHL EAX > 00000522: F6C120 TEST ECX $32 > 00000525: 7400 JE rel8 L.77 > 00000527: 8BD0 MOV EDX EAX > 00000529: 33C0 XOR EAX EAX > set_label L.77 > 0000052B: 23C3 AND EAX EBX > 0000052D: 23D6 AND EDX ESI > 0000052F: F7D3 NOT EBX > 00000531: F7D6 NOT ESI > declare_temp 4 4 Int.32 F tv.119[T$119] -88 > 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! > 00000536: 8B7DE8 MOV EDI tv.108[_a64] > declare_temp 4 4 Int.32 F tv.120[T$120] -92 > 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! > 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 > 0000053F: 23FB AND EDI EBX > 00000541: 23CE AND ECX ESI > 00000543: 0BF8 OR EDI EAX > 00000545: 0BCA OR ECX EDX > free_temp tv.120[T$120] > free_temp tv.119[T$119] > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 17:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308162149.D4E4A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:21:49 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Removed files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove no longer used 64bit insert/extract functions remove no longer used _lowbits/_highbits tables that NT386 used to use for 32bit insert/extract test code has nothing left to test now (there is still stuff in hand.c, but test_hand.c didn't test it) From jkrell at elego.de Tue Mar 9 17:09:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:09:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309160900.CF5352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:09:00 Modified files: cm3/scripts/python/: pylib.py Log message: fix newlines From jkrell at elego.de Tue Mar 9 17:10:08 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:10:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309161008.3D8192474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:10:08 Modified files: cm3/scripts/python/: pylib.py Log message: code to detect Visual C++ version from its banner, so we can build an .msi for every or almost every one (I'm missing some right now), preprocessing the string _MSC_VER is another good way From jkrell at elego.de Tue Mar 9 17:29:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:29:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309162937.904482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:29:37 Modified files: cm3/scripts/python/: pylib.py Log message: don't put cm3cg in NT386 packages From jkrell at elego.de Tue Mar 9 17:41:05 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:41:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309164105.1EB322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:41:05 Modified files: cm3/scripts/python/: pylib.py Log message: tag NT386 distribution file names with Visual C++ version e.g. cm3-std-NT386-d5.8.2-VC90.tgz, m3-std-NT386-d5.8.2-VC80.msi, etc. From jkrell at elego.de Tue Mar 9 17:56:19 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:56:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309165619.700AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:56:19 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: COPY from head: PPC64_DARWIN support remove PIC building some SPARC bootstraps don't put cm3cg in NT386 packages stamp NT386 package files with Visual C++ version remove leading underscore from ConvertFromCygwinPath, ConvertToCygwinPath so they are public remove 'base' and 'core' package sets some Interix stuff (which I think isn't needed anywhere) support for editing in -debug switch From jkrell at elego.de Wed Mar 10 09:43:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 9:43:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310084320.99E8B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 09:43:20 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86Rep.i3 Stackx86.i3 Stackx86.m3 Log message: selective 'INTEGER' => 'CARDINAL' From jkrell at elego.de Wed Mar 10 11:31:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:31:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103136.BDE3F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) From jkrell at elego.de Wed Mar 10 11:32:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:32:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103247.98D402474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:32:47 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Wed Mar 10 11:34:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103405.A42882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:05 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: when checking for case insensitive inequality, first check for case sensitive equality From jkrell at elego.de Wed Mar 10 11:34:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103456.7D46B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:56 Modified files: cm3/m3-libs/sysutils/src/: PathReprCommon.m3 Log message: fix typos in comments From jkrell at elego.de Wed Mar 10 11:37:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:37:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103756.9D3BB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:37:56 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: if asked to replace something with itself, just return the original without any searching From jkrell at elego.de Wed Mar 10 11:41:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:41:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104139.B6A712474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:41:39 Modified files: cm3/m3-libs/sysutils/src/: EnvUtils.m3 FSUtils.i3 FSUtils.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 MsgX.m3 OSSpecials.i3 PathRepr.i3 ProcessEnv.i3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 m3makefile cm3/m3-libs/sysutils/src/POSIX/: OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 m3makefile cm3/m3-libs/sysutils/src/WIN32/: OSSpecialsWin32.m3 PathReprWin32.m3 SystemWin32.m3 m3makefile cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 m3makefile cm3/m3-libs/sysutils/src/pm3/: TextUtils.m3 m3makefile Log message: remove $Id$, it adds noise when comparing branches I'll take the liberty of assuming $Id$ is not part of the license text that is usually adjacent to. From jkrell at elego.de Wed Mar 10 11:45:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:45:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104544.7AF4F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:45:44 Modified files: cm3/m3-libs/sysutils/src/: Confirmation.i3 Confirmation.m3 ConnectRdWr.m3 EnvUtils.i3 EnvUtils.m3 FSUtils.m3 FSUtilsUnsafe.i3 FastLex.i3 FingerprintFmt.i3 FingerprintFmt.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 OSSpecials.i3 PathReprCommon.m3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/sysutils/src/pm3/: RdExtras.m3 TextUtils.m3 Log message: remove whitespace at ends of lines From jkrell at elego.de Wed Mar 10 15:18:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:18:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310141843.A73942474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:18:43 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: compare operandPart when comparing stackp really something larger is bothering me, looking into the assertion failure when I try to remove unnecessary instructions from insert/extract We get into a situation where part of a value is in one of the correct registers, but hi is in low or vice versa, and in moving things around, we do the wrong thing. Like if we want return value in EDX:EAX and the value is currently in EAX:ECX, we do like: XCHG EAX,ECX ; put the low part in EAX where it belongs MOV EDX, EAX ; wrong, should be MOV EDX, ECX, or reverse ; the two instructions I don't know that there is a problem here in practise or not, since I've only seen it so far looking at uncommited changes. From jkrell at elego.de Wed Mar 10 15:22:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:22:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142256.0812A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:22:56 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: store operandPart := -1 whenever we store stackp := -1 From jkrell at elego.de Wed Mar 10 15:24:00 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:24:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142400.40C1A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:24:00 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: finish the change that follows errors with assertion failures From jkrell at elego.de Wed Mar 10 15:40:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:40:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144047.BD9A02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:40:47 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: just add comments From jkrell at elego.de Wed Mar 10 15:41:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:41:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144132.E0E692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:41:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: slight simplification, perhaps, in procedure swap From jkrell at elego.de Wed Mar 10 15:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145132.9770E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:51:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: safe keeping: this generates insert/extract better but either causes or reveals a register allocation problem, followed by an assertion failure; the register allocation problem can be seen here: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG EAX ECX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] 64bit return values are EDX:EAX. This has, by chance, the value in EAX:ECX, and then messes up converting it to EDX:EAX. From jkrell at elego.de Wed Mar 10 15:52:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:52:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145251.900B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:52:51 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: go back to version 1.131 From jkrell at elego.de Wed Mar 10 16:12:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:12:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310151231.8F9412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:12:31 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Now that I finally think enough, a nice little fix to the register allocator to handle when a multi register operand is partly in the right registers, but with the part mixed up. It yields us at the end of Long__Insert this: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG ECX EAX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] again it'd be nice if we had ECX:EAX in the first place instead of EAX:ECX, or even EDX:EAX. And then, a roundabout but understandable way to eliminate the unnecessary stores in insert/extract. The extra checking under -debug forces to rearrange the virtual stack and discard(), rather than just say dealloc_reg. If "location" could be "nowhere" that might help, but we have to chose between immediate, register, float stack, memory_variable. And then Modula-3 WITH either because of how it behaves or because of my confusion -- I think actually for reasons related to "safety", we have to "reevaluate" a few times -- each time we discard anything from the stack. Leading to a bit extra code but it is fairly clear. From jkrell at elego.de Wed Mar 10 16:49:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:49:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310154926.63AFE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:49:26 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: two small improvements 1) If we were trying to put 64bit value in EDX:EAX such as we assume is for a return value, and either part of the value wasn't in place, we would do work for both parts. The result was typically throwing in "xchg edx,edx" which does nothing. Now we only work on whatever part isn't where it should be. This could be seen e.g. in Long__Plus. Caught by adding assert to # from in swapreg. 2) If we are allocating a 64bit value and EAX is chosen for one of the registers, force it to be the low part. This saves an instruction in Long__Insert and easy to imagine elsewhere. There's really no downside. Unless maybe you are about to shift or rotate by a constant of 32 or more, or extract/insert with an offset of 32 or more (and even then, I think we can address that) If the high part is already in a register (i.e. EAX), then leave it there. I don't think this can happen since, like, we don't have a notion of "splitting" or "merging" allocation. e.g., ideally: stuff like: a := 0L or a := -1L would fit in one register or a := 0L; a := Long.Or(a, VAL(integer, LONGINT)) would be an immediate plus one register, instead of two registers From hosking at cs.purdue.edu Wed Mar 10 16:53:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 10:53:16 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100310103136.BDE3F2474001@birch.elegosoft.com> References: <20100310103136.BDE3F2474001@birch.elegosoft.com> Message-ID: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Mar 10 17:00:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 16:00:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Mar 2010 10:53:16 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 10 17:08:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 11:08:01 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: <49CA2A26-57BD-462F-97A6-A86B21107D50@cs.purdue.edu> OK. On 10 Mar 2010, at 11:00, Jay K wrote: > I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. > I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). > > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 10:53:16 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I thought we decided these hacks were not necessary moving forward. > If you want to build CM3 you need an up to date compiler... etc. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 10 Mar 2010, at 11:31, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Mar 10 18:04:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170405.2E11D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:04 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: replace e.g.: 00000022: B8 FF FF FF FF mov eax,0FFFFFFFFh 00000027: BA FF FF FF FF mov edx,0FFFFFFFFh with: 00000020: 83 C8 FF or eax,0FFFFFFFFh 00000023: 83 CA FF or edx,0FFFFFFFFh (mov reg, -1 with or reg, -1 -- smaller encoding, same meaning; both 32bit and 64bit operands) notice the code is a bit wierd, source type vs. dest type, and the number 4 is too creeping (this code should target AMD64_NT eventually) From jkrell at elego.de Wed Mar 10 18:04:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170431.684F72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:31 Modified files: cm3/m3-sys/m3back/src/: TWordN.i3 Log message: fix whitespace From jkrell at elego.de Wed Mar 10 21:52:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205230.445EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:30 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Handle when both registers are allocated to an operand, but in the wrong parts. e.g. we have EAX:EDX but want EDX:EAX. Not actually tested, nor an example seen, but I was thinking about it and it seems clear the previous code would do two swaps, leaving things incorrect. From jkrell at elego.de Wed Mar 10 21:52:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205254.4080C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: fix comment From jkrell at elego.de Wed Mar 10 21:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205625.B33062474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:56:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repition From jkrell at elego.de Wed Mar 10 21:57:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:57:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205733.45C8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:57:33 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repitition, should be equivalent From jkrell at elego.de Wed Mar 10 21:58:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:58:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205844.40A142474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:58:44 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: should be equivalent From jay.krell at cornell.edu Wed Mar 10 23:27:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 22:27:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? You know, that'd be a great hint to: - definitely definitely definitely definitely inline - if we know this thing existed, we could use it instead of a .c file. - along with the function's name for the invocations that aren't the function? Why provide the function anyway? In case someone takes the address? - Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> > <1.txt> > From hosking at cs.purdue.edu Thu Mar 11 01:57:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 19:57:17 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Yes, someone can pass the function as a parameter. I don't understand the rest of what you are saying. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 17:27, Jay K wrote: > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >> <1.txt> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 11 02:30:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 01:30:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. Granted at least two things: Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. And I'm inlined to just always inline anyway. (I still don't like the term "Long" here. It doesn't convey unsigned.) - Jay ________________________________ > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 19:57:17 -0500 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > > > Yes, someone can pass the function as a parameter. > > I don't understand the rest of what you are saying. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 10 Mar 2010, at 17:27, Jay K wrote: > > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x>>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > > <1.txt> > > From hosking at cs.purdue.edu Thu Mar 11 03:01:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 21:01:54 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? On 10 Mar 2010, at 20:30, Jay K wrote: > > If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. > > > That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. > > > That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. > > Granted at least two things: > Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. > And I'm inlined to just always inline anyway. > > > (I still don't like the term "Long" here. It doesn't convey unsigned.) > > > - Jay > > > > ________________________________ >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Wed, 10 Mar 2010 19:57:17 -0500 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> >> Yes, someone can pass the function as a parameter. >> >> I don't understand the rest of what you are saying. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 10 Mar 2010, at 17:27, Jay K wrote: >> >> >> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >> You know, that'd be a great hint to: >> >> - definitely definitely definitely definitely inline >> - if we know this thing existed, we could use it instead of a .c file. >> - along with the function's name for the invocations that aren't the function? >> >> >> Why provide the function anyway? In case someone takes the address? >> >> >> >> - Jay >> >> >> ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> >> <1.txt> >> >> From jay.krell at cornell.edu Thu Mar 11 05:10:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 04:10:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, ,,, , , , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu>, , <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> Message-ID: Long.LeftShift is not a great example. Sorry. Long.Shift, Long.Rotate, Long.Times, LongDivide. Those are or "could be" large. Currently the later three all call functions and are therefore short. Integer.Multiple, Divide, Remainder, similarly uncertain. They call functions, the functions aren't short. I was also thinking, some of these functions, esp. 64bit shift/rotate could be shorter as loops. But I think not worthwhile. To be clear, even though "parse.c" "never" generates function calls (except for set operations), the gcc backend itself often does. The functions are in libgcc. You know..I find it hard to decide about compiler generated function calls. Definitely for size optimization they can be a win. But I just somehow vaguely don't like them. In many cases, the decision is not difficult. set_singleton and set_member are good examples. They could be inlined and be very small. But Shift, Rotate, Multiply, Divide, it gets less clear. But no matter how large an inline form, I think when interface word/long maps directly to these operations, they should be inlined. And then if there are places that don't inline, they should call the "instantiations" in interface word/long. And then, furthermore, we should consider an interface for "Integer.Divide/Multiple/Remainder"? A place to park the possibly large code? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 21:01:54 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? > > On 10 Mar 2010, at 20:30, Jay K wrote: > >> >> If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. >> >> >> That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. >> >> >> That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. >> >> Granted at least two things: >> Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. >> And I'm inlined to just always inline anyway. >> >> >> (I still don't like the term "Long" here. It doesn't convey unsigned.) >> >> >> - Jay >> >> >> >> ________________________________ >>> Subject: Re: [M3commit] CVS Update: cm3 >>> From: hosking at cs.purdue.edu >>> Date: Wed, 10 Mar 2010 19:57:17 -0500 >>> CC: m3commit at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> >>> >>> Yes, someone can pass the function as a parameter. >>> >>> I don't understand the rest of what you are saying. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 10 Mar 2010, at 17:27, Jay K wrote: >>> >>> >>> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >>> You know, that'd be a great hint to: >>> >>> - definitely definitely definitely definitely inline >>> - if we know this thing existed, we could use it instead of a .c file. >>> - along with the function's name for the invocations that aren't the function? >>> >>> >>> Why provide the function anyway? In case someone takes the address? >>> >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 16:04:45 +0000 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> >>> >>> >>> >>> Fair enough. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 10:29:00 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >>> >>> >>> >>> On 8 Mar 2010, at 07:30, Jay K wrote: >>> >>> >>> >>> diff attached >>> >>> >>> If folks really want to use tables or function calls here, let me know. >>> >>> >>> The data was historically problematic, though we worked out the problems. >>> - It was initialized at runtime which has a race condition, fixed years ago. >>> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >>> >>> The data is still used by Word.Insert and Long.Insert is still a function, but those >>> are my next targets. >>> >>> >>> This is a case where the user does write a function call. Word.Extract or Long.Extract. >>> (So the function should have been called Long__Extract.) >>> >>> >>> - Jay >>> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >>> <1.txt> >>> >>> > From hosking at elego.de Thu Mar 11 06:24:29 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:24:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311052429.3EFD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:24:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Use BIT_FIELD_REF for extract_mn. From hosking at elego.de Thu Mar 11 06:36:35 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:36:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311053636.074602474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:36:35 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: A little easier to read. From hosking at elego.de Thu Mar 11 06:40:22 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054022.EDCE42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:40:22 Modified files: cm3/m3-sys/m3front/src/builtinWord/: Insert.mg Log message: Make use of insert_n and insert_mn. This allows simplified range checking for constant m/n. From hosking at elego.de Thu Mar 11 06:42:06 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:42:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054206.B81732474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:42:06 Modified files: cm3/m3-sys/m3middle/src/: M3CG.m3 M3CG_BinWr.m3 M3CG_Check.m3 M3CG_Ops.i3 M3CG_Wr.m3 cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Make arguments to insert_mn insert_n extract_mn extract_n CARDINAL. From jkrell at elego.de Thu Mar 11 16:29:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 11 Mar 2010 16:29:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311152914.4E6AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/11 16:29:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: stop outputing lines that end in just \r (unless caller actually gave us such a thing, which they don't) so I can stop dismissing this very annoying messagebox that also pauses to beep: --------------------------- Microsoft Developer Studio --------------------------- Lines ending with only a carriage return have been detected. These will be modified to include a line feed. --------------------------- OK --------------------------- This was occuring every time I open foo.molog, which is produced by cm3 -debug which I use heavily these days. related, most uses of Target.EOL should be Wr.EOL but that isn't changed here. From rcoleburn at elego.de Fri Mar 12 00:55:52 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 0:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311235552.F0BC62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 00:55:52 Modified files: cm3/scripts/install/windows/: cm3CommandShell.CMD Log message: Add features to look for root of cm3 installation in location of currently running CMD script, then in folders on PATH environment variable, before defaulting to "%SystemDrive%\cm3". Of course the "Root path" argument can still be used to force a specific location.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 01:26:19 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 1:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312002619.5E20F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 01:26:19 Modified files: cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd Log message: Add feature to search PATH env var as a last resort when trying to locate the root of the cm3 installation.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 04:27:46 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 4:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312032746.A46BC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 04:27:46 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Implement quick-fix for problem documented in Trac ticket #1082. The quick-fix is to change the default behavior on Windows such that CM3IDE does not terminate when the browser terminates. I've commented this quick-fix patch in the source code to make it easy to remove if/when we come up with a better solution. Note that if you already have a CM3_IDE.cfg file, it will need to be edited manually for the "start_browser" function, or you can just delete it and CM3IDE will recreate it using the new defaults the next time it runs. This quick-fix patch has no effect on non-Windows systems.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 07:03:44 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 7:03:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312060344.897122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 07:03:44 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Repair bug introduced with quick-fix patch.--R.Coleburn From jkrell at elego.de Fri Mar 12 12:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110412.6C4812474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:04:12 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Stackx86.m3 Log message: insert/extract offset/count INTEGER => CARDINAL, mostly From jkrell at elego.de Fri Mar 12 12:07:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:07:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110736.D5C882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:07:36 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 M3CG_Wr.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:09:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:09:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110928.3CD8D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:09:28 Modified files: cm3/m3-sys/m3front/src/misc/: WebInfo.m3 cm3/m3-sys/m3front/src/values/: Module.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111400.E06592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:00 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Utils.m3 WebFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111458.1D8A92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:58 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111643.5CD652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:16:43 Modified files: cm3/m3-sys/m3linker/src/: MxGen.m3 MxOut.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:19:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:19:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111925.4EA6A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:19:25 Modified files: cm3/m3-sys/m3loader/src/WIN32/: M3LoaderRd.m3 Log message: account for file size now being LONGINT and cast (VAL) to INTEGER From jkrell at elego.de Fri Mar 12 12:26:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112634.6324D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:34 Modified files: cm3/m3-sys/m3loader/src/: Main.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:26:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112658.E9A252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:58 Modified files: cm3/m3-sys/m3tests/src/c1/c130/: OWr.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113017.A525D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:30:17 Modified files: cm3/m3-sys/m3objfile/src/: MasmObjFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113428.E15362474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:34:28 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:36:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:36:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113600.D3D352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:36:00 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:38:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113851.7CAB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:38:51 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 M3Build.m3 Utils.i3 Utils.m3 Log message: CopyText => Copy just copy files directly no end of line conversion From jkrell at elego.de Fri Mar 12 12:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114010.08CE02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:40:09 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Log message: remove text_file: BOOLEAN parameter from PROCEDURE PullForBootstrap From jkrell at elego.de Fri Mar 12 12:42:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:42:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114214.614572474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:42:14 Modified files: cm3/m3-sys/m3middle/src/: M3File.i3 M3File.m3 Log message: remove PROCEDURE CopyText that does newline conversion From jkrell at elego.de Fri Mar 12 12:43:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:43:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114355.854482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:43:55 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: remove Target.EOL From jkrell at elego.de Fri Mar 12 12:44:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:44:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114443.5D53C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:44:43 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add feature so cm3 -Ddebug passes -debug down to the test cases -- they'll never pass that way, but extra information is generated that might be useful From jkrell at elego.de Fri Mar 12 12:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114610.A20E42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:46:10 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: remove commented code for 32bit LONGINT that catered to older m3back From rcoleburn at elego.de Sat Mar 13 02:11:24 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 2:11:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313011125.34CF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 02:11:24 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn From jay.krell at cornell.edu Sat Mar 13 05:47:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 04:47:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313011125.34CF12474001@birch.elegosoft.com> References: <20100313011125.34CF12474001@birch.elegosoft.com> Message-ID: This change is suspicious. I think it leaks. Please see http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/FSWin32.m3?rev=1.7;content-type=text%2Fplain for the pattern that is usually used. Granted, given the conservativeness of the collector -- it finds stuff in registers and the stack without a need for metadata telling it where the points are, and the fact that we no longer have VM-synchronization, I don't understand the need for the usual pattern. Maybe because it is willing to move stuff? Therefore a non-traced copy is made for C that won't ever move? - Jay > Date: Sat, 13 Mar 2010 02:11:24 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 10/03/13 02:11:24 > > Modified files: > cm3/examples/calling-c-win32/src/: OK.m3 > > Log message: > M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at elego.de Sat Mar 13 06:57:59 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 6:57:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313055759.BFEA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 06:57:59 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: Improve this example code by following the prescribed pattern of freeing the shared storage after it is no longer needed.--R.Coleburn From jkrell at elego.de Sat Mar 13 11:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 11:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313100917.133702474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 11:09:17 Added files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 m3makefile Log message: This program endeavors to exercise every sort of integer, float, address comparison, and some set compares, in order to support cleanup and improvement of comparison in m3back. If this isn't fleshed out further, it really belongs in the "c for code" test section. From jkrell at elego.de Sat Mar 13 13:12:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:12:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313121234.2D2122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:12:34 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add the various no overlap and minimal overlap cases that is: no_overlap_less: [0..1] compared to [2..3] no overlap greater: [2..3] compared to [0..1] min overlap less: [0..1] compared to [1..2] min overlap greater: [1..2] compared to [0..1] I have all these optimized for <, >, <=, >= where possible. Not yet = and #. Only for integer and longint, subranges, not yet for enums, not tested for constants. From jkrell at elego.de Sat Mar 13 13:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313122525.A06652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add enum cases From jkrell at elego.de Sat Mar 13 13:32:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123208.5933B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:08 Added files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 m3makefile Log message: a seperate test from p232: This program endeavors to exercise comparisons for subranges and enums that don't overlap or overlap only at the edge. This should probably be in the "c for code" section. What is being tested is that many of these functions return just a constant TRUE or FALSE. From jkrell at elego.de Sat Mar 13 13:32:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123236.BC2BE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:36 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: remove (most of) what was moved to p233 From jkrell at elego.de Sat Mar 13 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313131650.95B082474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:16:50 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add comparisons of CARDINAL to -1 and -2 It looks like I have this all working, except for: <*UNUSED*>PROCEDURE AddressLT0(a:ADDRESS):BOOLEAN=BEGIN RETURN a= NIL because min/max of address is 0/-1, instead 0/2^^32 or 2^^64 perhaps the signedness of address isn't so well defined and this should be left alone anyway. From jkrell at elego.de Sat Mar 13 14:36:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:36:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313133632.5FD172474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:36:32 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add the unusual case of single element subranges (two variables of such type are always equal, etc. (never not equal, always less-or-equal, always greater-or-equal, never less, never greater), and add comments From jkrell at elego.de Sat Mar 13 14:45:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:45:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313134559.5F7DC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:45:59 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: Fairly simple analysis to optimize comparison of subranges that either don't overlap at all, or only "on the edge" ("on the edge" means the max of one is equal to the min of the other or vice versa) I don't presume that this really helps much real world code, but it is pretty simple so shouldn't hurt. Probably it is rare to mix unequal subranges, let alone non-overlapping or barely overlapping, as well probably rare to compare subranges to constants outside the subrange (or again, "on the edge") This handles, integers, longints, enums, constants, but addresses don't work e.g. address < NIL should perhaps always be false. It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? I was surprised to see that they are separate. It also seemed odd to have to call ConstValue before GetBounds. Backends are not directly given the information for them to do this work, though more advanced analysis might regain the information. subranges and enums just end up as generally unbounded int32, etc. (backends do see range checks and can remember what they imply but I believe parameters are not range checked upon receipt, for example) see test case p233 (though it should probably move to the "c for code" section, since running it doesn't do anything, one reads the code and notices that many of the functions are optimized to just return a constant true or false) This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) compares in m3back, which has a pretty non-optimal implementation. From jay.krell at cornell.edu Sat Mar 13 14:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 13:47:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313134559.5F7DC2474001@birch.elegosoft.com> References: <20100313134559.5F7DC2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 14:45:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 14:45:59 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 > > Log message: > Fairly simple analysis to optimize comparison of subranges > that either don't overlap at all, or only "on the edge" > ("on the edge" means the max of one is equal to the min of the other > or vice versa) > > I don't presume that this really helps much real world code, but > it is pretty simple so shouldn't hurt. > Probably it is rare to mix unequal subranges, let alone non-overlapping > or barely overlapping, as well probably rare to compare subranges to > constants outside the subrange (or again, "on the edge") > > This handles, integers, longints, enums, constants, but addresses don't work > e.g. address < NIL should perhaps always be false. > > It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? > I was surprised to see that they are separate. > > It also seemed odd to have to call ConstValue before GetBounds. > > Backends are not directly given the information for them to do this work, though > more advanced analysis might regain the information. > subranges and enums just end up as generally unbounded int32, etc. > (backends do see range checks and can remember what they imply but > I believe parameters are not range checked upon receipt, for example) > > see test case p233 (though it should probably move to the "c for code" section, > since running it doesn't do anything, one reads the code and notices that > many of the functions are optimized to just return a constant true or false) > > This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) > compares in m3back, which has a pretty non-optimal implementation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 15:16:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:16:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313141602.EC5932474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:16:02 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: more test cases, some succeed (at being optimized), some do not. ORD(enum) vs. negative; these work ABS vs. negative; these work ABS vs. 0; these work -ABS vs. cardinal; the only optimizable case is neg_abs_vs_cardinal_GT and it doesn't work -ABS vs. 0; ditto -ABS vs. 1; many optimizable cases, none work ABS has a min of 0 negate of abs should have a max of 0 but is considered unbounded it looks like bounds do not propagate always as they could From jkrell at elego.de Sat Mar 13 15:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313142730.87A5D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:27:30 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: use interface Word, Long to get unsigned operations (I think they should have EQ/NE, instead of teahing people that they are the same as the signed operations..) From jkrell at elego.de Sat Mar 13 15:40:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:40:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313144021.E917A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:40:21 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove some uninteresting cases From jkrell at elego.de Sat Mar 13 15:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313145540.F15B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:55:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp is not reachable (and this isn't related to generalizations in m3middle/m3cg either; it is about a generalization m3back makes mapping a parameter to a larger set and then optimizing the newer values, none of which can ever occur) From jay.krell at cornell.edu Sat Mar 13 15:57:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 14:57:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313145540.F15B72474001@birch.elegosoft.com> References: <20100313145540.F15B72474001@birch.elegosoft.com> Message-ID: small diff attached, with whitespace ignored (as an IF was removed) more coming in this area soon.. > Date: Sat, 13 Mar 2010 15:55:40 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 15:55:40 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp > is not reachable (and this isn't related to generalizations > in m3middle/m3cg either; it is about a generalization m3back > makes mapping a parameter to a larger set and then optimizing > the newer values, none of which can ever occur) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 19:11:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 19:11:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313181114.B14E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 19:11:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 Log message: improve all integer compares, some/all set compares not yet: float compares old pattern: cmp setcc byte in memory xor reg,reg (any register, I believe) mov reg, memory new patterns, depending on comparison/types: xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} cmp setcc reg or cmp possibly with operands reversed sbb reg, reg neg reg or cmp possibly with operands reversed sbb reg, reg inc reg There is a little extra pressure on eax,ebx,ecx,edx, but we save an instruction and we avoid use of an in-memory temporary. The instruction could have been saved by using movzx as the manuals recommend anyway, instead of xor+mov. The sequences are used are based on optimized C. Basic problem here is setcc which only sets a byte but we generally want 32bit values. Possibly more to do here. The main difficulty developing this change was that I didn't initially restrict to RegistersForByteOperations. Small test cases worked ok but cases with more register pressure did not. see test p232 for a test that currently exercises some of this. From jay.krell at cornell.edu Sat Mar 13 19:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 18:12:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313181114.B14E22474001@birch.elegosoft.com> References: <20100313181114.B14E22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 19:11:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 19:11:14 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 > > Log message: > improve all integer compares, some/all set compares > not yet: float compares > > old pattern: > cmp > setcc byte in memory > xor reg,reg (any register, I believe) > mov reg, memory > > new patterns, depending on comparison/types: > xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} > cmp > setcc reg > > or > cmp possibly with operands reversed > sbb reg, reg > neg reg > > or > cmp possibly with operands reversed > sbb reg, reg > inc reg > > There is a little extra pressure on eax,ebx,ecx,edx, but > we save an instruction and we avoid use of an in-memory temporary. > The instruction could have been saved by using movzx as the manuals > recommend anyway, instead of xor+mov. > > The sequences are used are based on optimized C. > > Basic problem here is setcc which only sets a byte > but we generally want 32bit values. > > Possibly more to do here. > > The main difficulty developing this change was > that I didn't initially restrict to RegistersForByteOperations. > Small test cases worked ok but cases with more register pressure did not. > see test p232 for a test that currently exercises some of this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 14 06:29:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 6:29:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314052940.11B272474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 06:29:39 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: go back a version the codegen optimization is ok, but I confused "semantically const" with "opportunistically const" e.g. the following is not legal C: const int a = 1; /* ok */ const int b = a + 1; /* not ok */ int c[a]; /* not ok */ int F() { return 1; } /* ok */ int d = F(); /* not ok */ int e[F()]; /* not ok */ (I'm assuming c89 or such, not c9x.) compiler could optimize: int F1() { return 1; } int F2() { return F() + F1(); } /* => return 2 */ but that occurs "differently". From jkrell at elego.de Sun Mar 14 07:31:23 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 7:31:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314063123.8DFA52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 07:31:23 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: start removing cases that don't work and annotating function names with their expected constant value From jkrell at elego.de Sun Mar 14 11:38:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 11:38:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314103811.E03C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 11:38:11 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove unused import word/long From jkrell at elego.de Sun Mar 14 12:42:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 12:42:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314114239.6B9612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 12:42:39 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove more uninteresting cases, label all cases with expected value; a properly modified cm3 should issue a warning for each procedure From jkrell at elego.de Sun Mar 14 13:35:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 13:35:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314123552.C26EA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 13:35:52 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: call every function and verify they return the right value (which wasn't really ever the point, they always compiled correctly, just inefficiently From jkrell at elego.de Sun Mar 14 14:00:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 14:00:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314130032.4838D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 14:00:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: remove three dead lines left over from when 64bit shifts weren't inlined From jkrell at elego.de Sun Mar 14 16:42:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 16:42:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314154240.673312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 16:42:40 Added files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: initial copy of Atomic.mg, this version won't have all the switch statements From jkrell at elego.de Sun Mar 14 17:02:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:02:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314160230.D13612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:02:30 Modified files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg atomic.tmpl m3makefile Log message: provide a version without a bunch of code from switch statements, esp. for platforms that only have sequential memory models (note that x86 with lfense/sfence/mfence/whatever can do better) From jkrell at elego.de Sun Mar 14 17:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314161830.4E70C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:18:30 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "t" is usually for "type", spell it out (sometimes it is for text) From jkrell at elego.de Sun Mar 14 17:21:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:21:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314162107.9E4042474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:21:04 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'z' is apparently for "type_that_is_a_multiple_of_32bits" spell it out too; maybe a shorter name can be found but I don't think 'z' is it. From jay.krell at cornell.edu Sun Mar 14 17:35:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 16:35:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314162107.9E4042474001@birch.elegosoft.com> References: <20100314162107.9E4042474001@birch.elegosoft.com> Message-ID: Maybe "z" is for "zero extended"? - Jay > Date: Sun, 14 Mar 2010 17:21:04 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 17:21:04 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > 'z' is apparently for "type_that_is_a_multiple_of_32bits" > spell it out too; maybe a shorter name can be found > but I don't think 'z' is it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:23:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:23:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314172342.E94E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:23:42 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: flesh out all the atomic operations, including 8, 16, and 64 bit operations There's some improvement to be had here still. Mainly that we overuse interlocked compare exchange loops. Some operations don't need that, e.g. add, sub, xor. Sometimes even "or" and "and" don't need them either, but we aren't likely to have sufficient context to discover that. In particular, if caller throws out the returned old value, then a direct "lock or" or "lock and" instruction can be used, instead of an interlocked compare exchange. Compare the code to these two functions: char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is just two instructions including the ret. The first contains a loop. Also we might be able to get the zero flag more efficiently for some cases, e.g. the non-64 bit cases. We can xor a register up front, sete it, and mov into eax, instead of going through memory (same number of instructions probably, and increased register pressure). Also register allocater (procedure find) should get an explicit flag to force the ecx:ebx allocation (and edx:eax). We should also try inlined tests, as opposed to interface atomic, and verify we don't unnecessarily enregister the atomic variable's address. That is needed in testing so far since I've just been looking at m3core. (ie: more testing, not just looking at m3core) We should also perhaps implement looser load/store where we only have a barrier on one side instead of both. Presently every atomic load/store is both preceded and followed by a serializing xchg. We should also consider if the barrier variable should be one widely shared global instead of everyone having to waste 4 bytes of stack for it. Note that AtomicLongint__Swap doesn't return the right value currently. Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? Kind of like the funny thing AtomicLongint__Swap does? (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary value for the first try: 0). That is to say, AtomicLongint__Load/Store are not presently atomic! No other correctness problems known. From jay.krell at cornell.edu Sun Mar 14 18:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314172342.E94E22474001@birch.elegosoft.com> References: <20100314172342.E94E22474001@birch.elegosoft.com> Message-ID: > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Sun Mar 14 18:31:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:31:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314172342.E94E22474001@birch.elegosoft.com>, Message-ID: searched the web: http://niallryan.com/node/137 shows 64 bit atomic read/write on x86. Including using floating point to do it..is it right? I'm inclined to implement the non-fp method. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:41:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:41:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174108.9D8772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:41:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Load per http://niallryan.com/node/137 some cleanup AtomicLongint__Store not right yet From jkrell at elego.de Sun Mar 14 18:42:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:42:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174227.AC1C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:42:27 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "type_that_is_a_multiple_of_32bits" => "type_multiple_of_32" It is a bit shorter. We'll see how it goes. From jkrell at elego.de Sun Mar 14 19:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181119.4468E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:11:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Store to be atomic see http://niallryan.com/node/137 I use the lock cmpxhg8b method, not the float method. Note that all the AtomicLongint functions require a "new" processor. From jkrell at elego.de Sun Mar 14 19:13:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:13:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181311.545C42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:13:11 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Preserve signedness a bit: 'Word64' => 'type' Probably doesn't matter. From jkrell at elego.de Sun Mar 14 19:17:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:17:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181743.7795F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:17:43 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: add CompareOpNames From hosking at cs.purdue.edu Sun Mar 14 19:31:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 14:31:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314154240.673312474001@birch.elegosoft.com> References: <20100314154240.673312474001@birch.elegosoft.com> Message-ID: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! On 14 Mar 2010, at 16:42, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 16:42:40 > > Added files: > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > Log message: > initial copy of Atomic.mg, this version won't have all the switch statements From hosking at elego.de Sun Mar 14 19:35:10 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314183510.9AAF22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:35:10 Modified files: cm3/m3-libs/m3core/src/atomic/: atomic.tmpl m3makefile Removed files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: Remove premature and irrational optimization. The compiler inlines the non-switch versions. There is no need for this overspecialization. From hosking at elego.de Sun Mar 14 19:49:31 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314184932.1A1AE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:49:31 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: No-one uses the strings. From jay.krell at cornell.edu Mon Mar 15 02:44:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:44:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> References: <20100314154240.673312474001@birch.elegosoft.com>, <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> Message-ID: The generated code was awful otherwise. All these big switch statements, only to do the same thing in each one. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 14 Mar 2010 14:31:35 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! > > On 14 Mar 2010, at 16:42, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/14 16:42:40 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > > > Log message: > > initial copy of Atomic.mg, this version won't have all the switch statements > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:45:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:45:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314184932.1A1AE2474001@birch.elegosoft.com> References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Mar 15 02:47:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 21:47:25 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: > I was using them. It is easy to imagine they'll be used again, while debugging. > > - Jay > > > Date: Sun, 14 Mar 2010 19:49:31 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/14 19:49:31 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: M3CG.i3 > > > > Log message: > > No-one uses the strings. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:54:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:54:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> References: <20100314184932.1A1AE2474001@birch.elegosoft.com>, , <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Message-ID: I removed them once I got my code working. But we have this sort of thing in general. - Jay From: hosking at cs.purdue.edu Date: Sun, 14 Mar 2010 21:47:25 -0400 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 15 03:29:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:29:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315022938.9D22A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:29:38 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: Fill in *a lot* more now that m3back implements everything. Notice that a few Refany cases are commented out, I couldn't figure out a way to call them (inc, dec, or, xor, and). From jkrell at elego.de Mon Mar 15 03:33:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315023307.9A5B62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:33:06 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: return rather than just eval IsLockFree() From jkrell at elego.de Mon Mar 15 03:40:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:40:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315024017.886B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:40:16 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: just one fence per fence test From jkrell at elego.de Mon Mar 15 10:55:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 10:55:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315095514.B7E772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 10:55:14 Modified files: cm3/scripts/python/: pylib.py Log message: fix long standing problem where do-pkg.py doesn't correctly order (or filter) packages given on command line From jkrell at elego.de Mon Mar 15 11:44:24 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 11:44:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315104424.0A2202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 11:44:24 Modified files: cm3/scripts/python/: do-cm3-all.py do-cm3-min.py do-cm3-std.py make-dist.py pylib.py Log message: order packages (some scenarios already did, but some did not) support package groups this makes do-pkg.py basically like do-cm3.cmd read scripts/pkginfo.txt instead of using local copy From jkrell at elego.de Mon Mar 15 14:20:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:20:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132035.6D8F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:20:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. From jkrell at elego.de Mon Mar 15 14:23:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:23:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132311.718CA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:23:11 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back a version: just always/save restore all 3 non-volatiles a compromise shortly that saves up front, possibly nop-ing out, and only restores what is needed From jkrell at elego.de Mon Mar 15 15:35:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:35:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143550.C8D2D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:35:50 Modified files: cm3/m3-sys/m3objfile/src/: NTObjFile.m3 M3ObjFile.i3 Log message: provide a function 'backup()' that lets caller seek backwards from the cursor; this should afford m3back something cleaner in generating epilogues, though still not great From jkrell at elego.de Mon Mar 15 15:36:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:36:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143612.04DFD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:36:11 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: don't compile MasmObjFile, it isn't used From jkrell at elego.de Mon Mar 15 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315144014.C608D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:40:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: Do something cleaner when generating prologues. In the interest of an optimization that saves an instruction from many many (all?) functions, the original authors often produce an epilogue by punching through abstraction boundaries and using objfile.patch. Worse, they sometimes do that, sometimes use equivalent code that goes through the layers. With this change, instead, we backup(5) and then use the clearer version. Unfortunately, if nothing else done, that leaves us trying to fixup the branch that we wiped out (its use of the label to the end of function. So compensate slightly in Codex86.m3. This is trading one ugliness for another. Perhaps something better can be found. I had something that compared to last_exitbranch in codex86.m3 but that wasn't quite right and introduced e.g. one instruction difference in RTHeapMap.m3. From jkrell at elego.de Mon Mar 15 16:06:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:06:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315150635.6BAF82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:06:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: Remove from one to three instructions from small functions. By tracking which non-volatile registers are used and only saving/restoring them. Unfortunately, until we are more sophisticated, we have to pay for the size for the push instructions, but we nop them out if they aren't needed, and only generating the needed pops. (We should look into two and three byte nops, but presently I just use one byte nops. The pushes are each one instruction. Theoretically, nop is faster than push, though I should check. Plus, nop saves us from doing a pop.) Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. Register allocator should probably favor volatile registers over non-volatile. Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) I noticed an ancient bug in doing this work. Functions with >4K frames need to call chkstk or equivalent. Specifically, stack pages must be touched in order. call naturally touches a page. Or, side motivation: match what the C compiler does. It is correct. (See, we also reserve room for sub esp,foo, for 32bit foo, even though many functions save save 3 bytes and use an 8bit value and some unusual functions can skip the entire thing (if foo = 0)) We can issue errors for such functions and see if any turn up. See test case p234 (not commited yet). Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. corrupt, set_reg, movop1, load_ind should suffice. From jkrell at elego.de Mon Mar 15 16:12:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:12:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315151237.264CF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:12:36 Added files: cm3/m3-sys/m3tests/src/p2/p234/: Main.m3 m3makefile Log message: add test that uses or doesn't use non-volatile registers perhaps should be moved to the "c for code" section We run it, make sure it doesn't crash, but the real point is codegen details. From jay.krell at cornell.edu Mon Mar 15 16:15:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 15:15:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100315150635.6BAF82474001@birch.elegosoft.com> References: <20100315150635.6BAF82474001@birch.elegosoft.com> Message-ID: diff attached, it is pretty simple > Date: Mon, 15 Mar 2010 16:06:35 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/15 16:06:35 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 > Stackx86.m3 > > Log message: > Remove from one to three instructions from small functions. > By tracking which non-volatile registers are used and only saving/restoring them. > Unfortunately, until we are more sophisticated, we have to pay for the size > for the push instructions, but we nop them out if they aren't needed, > and only generating the needed pops. (We should look into two and three > byte nops, but presently I just use one byte nops. The pushes are each > one instruction. Theoretically, nop is faster than push, though I should check. > Plus, nop saves us from doing a pop.) > > Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. > > Register allocator should probably favor volatile registers over non-volatile. > Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) > > I noticed an ancient bug in doing this work. > Functions with >4K frames need to call chkstk or equivalent. > Specifically, stack pages must be touched in order. call naturally > touches a page. Or, side motivation: match what the C compiler does. It is correct. > (See, we also reserve room for sub esp,foo, for 32bit foo, even > though many functions save save 3 bytes and use an 8bit value and > some unusual functions can skip the entire thing (if foo = 0)) > > We can issue errors for such functions and see if any turn up. > > See test case p234 (not commited yet). > > Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. > corrupt, set_reg, movop1, load_ind should suffice. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 15 16:26:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:26:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315152608.D59162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:26:08 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Be certain to get the register allocation correct for 64bit interlocked compare exchange. The code could be reduced but is very clear this way. We should probably have special flags (Force values) for ret64 (return_double_integer) as well as interlocked compare exchange double integer parameters. For now I infer these cases from aspects that could occur in less constrained situations, leading to unnecessary register moves (i.e. if we already for some reason have something in EAX:EDX, we shouldn't change it to EDX:EAX unless we actually have to.) From jkrell at elego.de Mon Mar 15 23:21:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 23:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315222155.833692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 23:21:55 Added files: cm3/m3-sys/m3back/src/doc/: frames.txt Log message: some notes on current, ideal, and correct patterns, based on C compiler output What we have is usually correct, rarely ideal, and sometimes wrong. In particular, we are not ideal for common case of functions with fewer than 128 bytes of locals. We use a 4 byte constant where a 1 byte constant suffices. Or the unusual cases of no locals/parameters. We are wrong for functions with more than 4K of locals: need to call chkstk. Let's at least try to fix the second case soon, but without making the usual cases larger. From jkrell at elego.de Tue Mar 16 11:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316103800.04B492474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:37:59 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: write debug output integers the old way: the new way isn't so important any longer, and it looks like this format *might* be readable From jkrell at elego.de Tue Mar 16 11:42:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:42:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104247.02FCC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:42:46 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: fix (looks like I had copied from release?) From jkrell at elego.de Tue Mar 16 11:45:14 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:45:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104514.4BE4D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:45:14 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: slightly more vertically dense: save two lines From jkrell at elego.de Tue Mar 16 14:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 14:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316132706.D92102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 14:27:06 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: put back MasmObjFile for m3staloneback From jkrell at elego.de Tue Mar 16 17:29:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 17:29:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316162908.048D22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 17:29:07 Modified files: cm3/scripts/python/: pylib.py Log message: reasonable hack: ignore package names that end '.py' -- these are argv[0] From wagner at elego.de Tue Mar 16 22:51:59 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 16 Mar 2010 22:51:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316215159.9892F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/16 22:51:59 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: list Debian and MSI packages, too From jkrell at elego.de Wed Mar 17 17:33:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:33:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163344.780D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:33:44 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: use fork1() on Solaris in case built/running on pre-Solaris 2.10 and using the libraries in which fork==forkall (at some point should setup a pre 2.10 machine?) From jkrell at elego.de Wed Mar 17 17:35:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:35:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163532.B486E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:35:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: if defined => ifdef in previous From jkrell at elego.de Wed Mar 17 18:02:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:02:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170257.1CB462474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:02:57 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: for now put back set_member and set_singleton, so I haven't to rebuild everything From jkrell at elego.de Wed Mar 17 18:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170346.8E99C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:03:46 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: Longer name for parameter From pmckinna at elego.de Thu Mar 18 11:50:17 2010 From: pmckinna at elego.de (Peter McKinna) Date: Thu, 18 Mar 2010 11:50:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105018.01F342474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 10/03/18 11:50:17 Modified files: cm3/m3-comm/netobj/tests/perf/src/: m3makefile Log message: Fixed quotes From jkrell at elego.de Thu Mar 18 11:55:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 11:55:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105548.99CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 11:55:48 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: cleanup to use and factor out the "safe double free" pattern, e.g. procedure Close(var i) if i >= 0 close(i) i = -1 This does not address the pthreads hangs. From jkrell at elego.de Thu Mar 18 12:12:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 12:12:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318111213.C0B7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 12:12:13 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: small part of cvsup fix - initialize stuff in InitActivations instead of depending on static initialization It used to look like this anyway I think. - change some variables to CARDINAL From jkrell at elego.de Fri Mar 19 18:07:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 19 Mar 2010 18:07:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100319170759.3D67D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/19 18:07:59 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix newlines From jkrell at elego.de Sat Mar 20 08:10:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:10:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320071045.ED2692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:10:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back div/mod helpers for compatibility with older backend, I was still using them a while From jkrell at elego.de Sat Mar 20 08:56:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:56:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075611.0313F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:56:10 Added files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add some tests for set_lt, le, gt, le; I find this code a bit hard to understand From jkrell at elego.de Sat Mar 20 08:59:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:59:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075916.38C252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:59:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: implement set_gt(a,b) as set_lt(b,a) implement set_ge(a,b) as set_le(b,a) Really the frontend or backend should make this transform. From jkrell at elego.de Sat Mar 20 09:22:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 9:22:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320082218.82AA42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 09:22:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test; not seeing commit mail? From jay.krell at cornell.edu Sat Mar 20 09:21:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Mar 2010 08:21:58 +0000 Subject: [M3commit] test Message-ID: test; not seeing commit mail? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mand at elego.de Sat Mar 20 19:20:27 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:20:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182027.3E2762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:20:27 Modified files: cm3/: README Log message: Trivial text edit for test purposes. Sorry for the spam. From mand at elego.de Sat Mar 20 19:21:58 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:21:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182158.C7A652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:21:58 Modified files: cm3/: README Log message: Cleanin up after commit mail test.... From jkrell at elego.de Sat Mar 20 21:40:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 21:40:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320204039.993E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 21:40:39 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: new file, empty to start From jkrell at elego.de Sun Mar 21 02:35:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 2:35:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321013545.5C8252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 02:35:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test commit mail; some recent commits here didn't show up; no diff here From jkrell at elego.de Sun Mar 21 10:28:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092809.55CF72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:04 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: fix making Debian packages From jkrell at elego.de Sun Mar 21 10:28:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092836.82E552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:36 Modified files: cm3/scripts/python/: pylib.py Log message: fix making Debian packages From jkrell at elego.de Mon Mar 22 05:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 22 Mar 2010 5:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100322042154.CAA7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/22 05:21:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcess.m3 Log message: remove newlines at end of file From hosking at elego.de Thu Mar 25 02:45:16 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 25 Mar 2010 2:45:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100325014517.5E98A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/25 02:45:16 Modified files: cm3/m3-sys/m3front/src/misc/: M3Front.m3 Log message: We have a decent collector. From mand at elego.de Fri Mar 26 22:53:59 2010 From: mand at elego.de (Michael Anderson) Date: Fri, 26 Mar 2010 22:53:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100326215400.0AC302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/26 22:53:59 Modified files: cm3/www/: todo.html Log message: Trivial text edit to test after server upgrade. Sorry for the spam. From jkrell at elego.de Sat Mar 27 09:56:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085615.C13DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:15 Modified files: cm3/m3-tools/cvsup/client/src/: Auth.i3 Auth.m3 BackoffTimer.i3 BackoffTimer.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 Detailer.i3 Detailer.m3 EventSync.i3 EventSync.m3 FSClient.i3 FSClient.m3 FileUpdater.i3 FileUpdater.m3 Fixup.i3 Main.m3 RCSUpdater.i3 RCSUpdater.m3 Receive.i3 Receive.m3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 SupFile.i3 SupFile.m3 SupGUI.i3 SupGUI.m3 SupGUIFake.m3 TextPortLogger.i3 TextPortLogger.m3 TextVBTLogger.i3 TextVBTLogger.m3 TreeList.i3 TreeList.m3 Updater.i3 Updater.m3 Version.i3 cm3/m3-tools/cvsup/cvpasswd/src/: Main.m3 Secret.i3 Secret.m3 Upass.i3 cm3/m3-tools/cvsup/server/src/: AccessRules.i3 AccessRules.m3 ClassDB.i3 ClassDB.m3 ClientClass.i3 ClientClass.m3 FSServer.i3 FSServer.m3 FSServerRep.i3 FSServerU.m3 FileInfo.i3 FileInfo.m3 Main.m3 ParsedDelta.i3 ParsedDelta.m3 Passwd.i3 Passwd.m3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 Version.i3 cm3/m3-tools/cvsup/suplib/src/: Attic.i3 Attic.m3 AuthMD5.i3 AuthMD5.m3 CText.i3 CVProto.i3 CVProto.m3 CVTree.i3 CVTree.m3 ChannelMux.i3 ChannelMux.m3 DevT.i3 DirEntry.i3 DirEntry.m3 ErrMsg.i3 ErrMsg.m3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 ExecRec.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.i3 FileID.m3 FileStatus.i3 FileStatus.m3 FileStatusRaw.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 GzipError.i3 GzipError.m3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 IOWatchDog.i3 IOWatchDog.m3 LockFile.i3 LockFile.m3 Logger.i3 Logger.m3 LoggerClass.i3 MD5.i3 MD5.m3 MD5Digest.i3 MD5Digest.m3 MD5Wr.i3 MD5Wr.m3 MySyslog.i3 PathComp.i3 PathComp.m3 ProcTitle.i3 RCSAccess.i3 RCSAccess.m3 RCSDate.i3 RCSDate.m3 RCSDelta.i3 RCSDelta.m3 RCSDeltaClass.i3 RCSEdit.i3 RCSError.i3 RCSFile.i3 RCSFile.m3 RCSKeyword.i3 RCSKeyword.m3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSRevNum.i3 RCSRevNum.m3 RCSString.i3 RCSString.m3 RCSTag.i3 RCSTag.m3 Reaper.i3 Reaper.m3 RsyncBlock.i3 RsyncBlock.m3 RsyncFile.i3 RsyncFile.m3 SigHandler.i3 SigHandler.m3 SplitLogger.i3 SplitLogger.m3 StatusFile.i3 StatusFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 TokScan.i3 TokScan.m3 Uglob.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 UnixMisc.i3 UnixMisc.m3 WatchDog.i3 WatchDog.m3 WrLogger.i3 WrLogger.m3 cm3/m3-tools/cvsup/suplib/src/FreeBSD/: FileAttrOS.i3 FileAttrOS.m3 ProcTitle.m3 UProcTitle.i3 cm3/m3-tools/cvsup/suplib/src/POSIX/: FileAttrOS.m3 ProcTitle.m3 cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: DevT.m3 cm3/m3-tools/cvsup/suplib/src/text_cm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suplib/src/text_pm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suptcp/src/POSIX/: SockOpt.i3 SockOptFBSD.m3 SockOptOther.m3 cm3/m3-tools/cvsup/suptcp/src/common/: StreamRd.i3 StreamRdClass.i3 StreamRdClass.m3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPMisc.i3 Log message: remove $Id$, see scripts/python/remove-id.py From jkrell at elego.de Sat Mar 27 09:56:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085649.D7D972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:49 Added files: cm3/scripts/python/: remove-id.py Log message: automate removing $Id$ From jkrell at elego.de Sun Mar 28 01:13:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001322.9516B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:13:22 Modified files: cm3/m3-tools/cvsup/: Makefile cm3/m3-tools/cvsup/client/: Makefile cm3/m3-tools/cvsup/client/src/: m3makefile cm3/m3-tools/cvsup/config/src/: m3makefile cm3/m3-tools/cvsup/cvpasswd/: Makefile cm3/m3-tools/cvsup/cvpasswd/src/: m3makefile cm3/m3-tools/cvsup/doc/: Makefile cm3/m3-tools/cvsup/server/: Makefile cm3/m3-tools/cvsup/server/src/: m3makefile cm3/m3-tools/cvsup/suplib/: Makefile cm3/m3-tools/cvsup/suplib/src/: m3makefile cm3/m3-tools/cvsup/suplib/src/FreeBSD/: m3makefile cm3/m3-tools/cvsup/suplib/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: m3makefile cm3/m3-tools/cvsup/suplib/src/libglob/: m3makefile cm3/m3-tools/cvsup/suplib/src/libmd/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_cm3/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_pm3/: m3makefile cm3/m3-tools/cvsup/suptcp/: Makefile cm3/m3-tools/cvsup/suptcp/src/: m3makefile cm3/m3-tools/cvsup/suptcp/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suptcp/src/common/: m3makefile Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001541.22C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:15:41 Modified files: cm3/m3-tools/cvsup/: Acknowledgments Announce Blurb Install cm3/m3-tools/cvsup/client/src/: SyncQueue.ig SyncQueue.mg cm3/m3-tools/cvsup/doc/: Attributes Checkouts Protocol faqgen.awk cm3/m3-tools/cvsup/examples/: README cm3/m3-tools/cvsup/suplib/src/: Merger.ig Merger.mg UnixMiscC.c cm3/m3-tools/cvsup/suplib/src/libglob/: fnmatch.c fnmatch.h cm3/m3-tools/cvsup/suplib/src/libmd/: md5.h md5c.c cm3/m3-tools/cvsup/suptcp/src/: README cm3/m3-tools/cvsup/suptcp/src/POSIX/: SupTCP.m3 SupTCPHack.i3 SupTCPHack.m3 SupTCPHackNull.m3 SupTCPPosix.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:17:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:17:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001701.646132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:17:01 Modified files: cm3/m3-tools/cvsup/client/src/: SupGUI.fv cvsup.1 syncqueue.tmpl cm3/m3-tools/cvsup/contrib/cvsup2httplog/: cvsup2httplog cm3/m3-tools/cvsup/contrib/cvsupchk/: cvsupchk cm3/m3-tools/cvsup/cvpasswd/src/: cvpasswd.1 cm3/m3-tools/cvsup/quake/: cvsup.quake cm3/m3-tools/cvsup/server/src/: cvsupd.8 cm3/m3-tools/cvsup/suplib/src/: merger.tmpl cm3/m3-tools/cvsup/suplib/src/libmd/: md5.copyright md5hl.c cm3/m3-tools/cvsup/suptcp/src/common/: SupTCP.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 11:07:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:07:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328090717.258542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:07:17 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: no need for an "object", just make everything global From jkrell at elego.de Sun Mar 28 11:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328091049.DDB102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:10:49 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: expand critical section in shutdown From jkrell at elego.de Sun Mar 28 11:31:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:31:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093100.CC7712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:31:00 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 RTProcess.i3 RTProcessC.c m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: cvsup/pthread_atfork fixes From jkrell at elego.de Sun Mar 28 11:33:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093313.0DA382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:33:11 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: fix to work with pthreads, or with user thread revision, where fork() doesn't leave all threads running From jkrell at elego.de Sun Mar 28 12:07:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100747.0C4422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:07:46 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 m3core.h Log message: partial merge from head: add calling conventions From jkrell at elego.de Sun Mar 28 12:09:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:09:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100907.E147B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:09:07 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 platforms.quake Log message: copy from head: add PPC64_DARWIN From jkrell at elego.de Sun Mar 28 12:13:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:13:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328101341.497F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:13:41 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.m3 Log message: copy from head: whitespace only From jkrell at elego.de Sun Mar 28 12:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103449.63A522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:34:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.i3 m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: Tag: release_branch_cm3_5_8 ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Added files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcessC.c Log message: merge cvsup/pthread_atfork changes from head to release From jkrell at elego.de Sun Mar 28 12:36:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:36:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103619.DF5F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:36:19 Modified files: cm3/m3-tools/cvsup/suplib/src/: Tag: release_branch_cm3_5_8 SigHandler.m3 Log message: copy from head for pthreads compatibility (fork() leaves just one thread, userthreads this way now too) From jkrell at elego.de Sun Mar 28 12:38:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:38:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103858.2C6222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:38:58 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Log message: fix From wagner at elego.de Sun Mar 28 15:07:02 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328130702.734C62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:07:02 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: temporarily turn on command tracing From wagner at elego.de Sun Mar 28 15:33:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:33:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328133324.CBC312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:33:24 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: disable command tracing again From jkrell at elego.de Mon Mar 29 20:47:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 20:47:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329184755.5D2D4CC37C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 20:47:55 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: change Multiplier from a variable to a constant From jkrell at elego.de Mon Mar 29 21:05:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 21:05:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329190516.7304F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 21:05:16 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: make it clearer From hosking at elego.de Mon Mar 29 21:13:19 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 29 Mar 2010 21:13:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329191319.BE5EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/29 21:13:19 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: Cleaner code (don't obfuscate history). No need for initialization of fields when the initializer can do that. From jkrell at elego.de Tue Mar 30 11:46:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 30 Mar 2010 11:46:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100330094652.3FF612474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/30 11:46:52 Modified files: cm3/m3-libs/m3core/src/types/: m3makefile Log message: include Int64 on NT386 From jkrell at elego.de Wed Mar 31 15:17:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:17:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331131727.7D1E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:17:27 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 UnixC.c Log message: add Unix.tell, at least for Win32 and Solaris, real goal is to add minimal Unix on Win32, and then run libm3 tests From jkrell at elego.de Wed Mar 31 15:34:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133421.BBF382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:34:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: Unix__tell here too From jkrell at elego.de Wed Mar 31 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133543.E90102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:35:43 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usocket.c m3makefile cm3/m3-libs/m3core/src/unix/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/WIN32/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/WIN32/: Unix.i3 Uuio.i3 Log message: greatly increase availability of src/unix on Win32, as much of it is actually provided by msvcr*dll From jkrell at elego.de Wed Mar 31 15:54:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:54:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331135417.510EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:54:16 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: better fallbacks for InitUserName, InitUserHome From jkrell at elego.de Mon Mar 1 05:34:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 5:34:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301043402.65E792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 05:34:02 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: move e_test use down below definition, so it works From jkrell at elego.de Mon Mar 1 11:55:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:55:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105536.BA6F32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:55:36 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: VAL(filesize, CARDINAL) to fix compilation From jkrell at elego.de Mon Mar 1 11:56:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:56:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105614.DD2B52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:56:14 Modified files: cm3/m3-libs/libm3/tests/os/src/: OSTest.m3 Log message: INTEGER just in case From jkrell at elego.de Mon Mar 1 11:57:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 11:57:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301105754.A5D862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 11:57:54 Modified files: cm3/m3-libs/libm3/tests/os/src/: Tag: release_branch_cm3_5_8 OSTest.m3 Log message: from head: VAL(filesize, INTEGER) to fix compilation From jkrell at elego.de Mon Mar 1 13:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 13:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301125437.9F27D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 13:54:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: work in progress to inline all 64bit shifts (and then rotates) the 64bit shift code in particular in the AMD manual is around 6 instruction however before we do that: teach unOp about double shift (aka shift by ecx) not yet used, as these cases still call functions split up the double ops into separate functions for readability: not_double, add_double, add_double_immediate, etc. (not, negate, add, subtract, compare, immediate and not; bigger things like multiply/divide generate function calls at a higher level, currently; given that our complicated single precision divide was inlined, probably will inline that for double, probably multiple too; while the result is bloated, I like the idea of reducing hand.c, and longint use on 32bit targets maybe ok to bloat?) also goal to have less duplication of the various logic such as left vs. right vs. "signed" shift, the compares to 32, 64, etc. at least move the code into fewer functions also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split into something that seems less hoky. Part of the issue is that other than oNOT, and separate functions like swapOp, movOp, nothing is really "just loop over the parts" From jay.krell at cornell.edu Mon Mar 1 13:57:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Mar 2010 12:57:43 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100301125437.9F27D2474001@birch.elegosoft.com> References: <20100301125437.9F27D2474001@birch.elegosoft.com> Message-ID: attached btw, other than the commit mail, the changelog should have a clickable link. > Date: Mon, 1 Mar 2010 13:54:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/01 13:54:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 > > Log message: > work in progress to inline all 64bit shifts (and then rotates) > the 64bit shift code in particular in the AMD manual is around 6 instruction > > however before we do that: > > teach unOp about double shift (aka shift by ecx) > not yet used, as these cases still call functions > > split up the double ops into separate functions for readability: > not_double, add_double, add_double_immediate, etc. > (not, negate, add, subtract, compare, immediate and not; bigger > things like multiply/divide generate function calls at a higher level, currently; > given that our complicated single precision divide was inlined, probably will > inline that for double, probably multiple too; while the result is bloated, > I like the idea of reducing hand.c, and longint use on 32bit targets > maybe ok to bloat?) > > also goal to have less duplication of the various logic such > as left vs. right vs. "signed" shift, the compares to 32, 64, etc. > at least move the code into fewer functions > > also stretch goal is to alter/eliminate the binop/binop1/binopWithShiftCount split > into something that seems less hoky. Part of the issue is that > other than oNOT, and separate functions like swapOp, movOp, nothing is really > "just loop over the parts" > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 1 15:25:22 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 1 Mar 2010 15:25:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100301142522.44AD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/01 15:25:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: fix and slightly extend From jkrell at elego.de Tue Mar 2 13:50:12 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:50:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125012.EDEEE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:50:12 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: case and whitespace From jkrell at elego.de Tue Mar 2 13:52:29 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:52:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125229.A8E4B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:52:29 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: somewhat consolidate shifting code no more "binOpWithShiftCount" inline all 64bit shifts, even when no constants involved (constants get inlined better) worst cases: shift right 64 (from the AMD manual): 00002217: 0F AD D3 shrd ebx,edx,cl 0000221A: D3 EA shr edx,cl 0000221C: F6 C1 20 test cl,20h 0000221F: 74 04 je 00002225 00002221: 8B DA mov ebx,edx 00002223: 33 D2 xor edx,edx 00002225: shift left 64 (from the AMD manual): 0000244B: 0F A5 DA shld edx,ebx,cl 0000244E: D3 E3 shl ebx,cl 00002450: F6 C1 20 test cl,20h 00002453: 74 04 je 00002459 00002455: 8B D3 mov edx,ebx 00002457: 33 DB xor ebx,ebx 00002459: Those sequences are quite subtle. I'm not sure I understand. Shift by between 32 and 63: The "wrong" register is shifted, but it is done modulo-32, so the correct result is had, in the "wrong" register then the register is moved to its correct place. That is: edx:eax << 33 is straightforwardly, after testing if the shift count is >32: edx = eax edx <<= 1 (shift count - 32) eax = 0 however the above does the shift before the move, since the modulo makes it correct: eax <<= (33 % 32) which is eax <<= 1 edx = eax eax = 0 The way it detects >=32 is very subtle to me. It checks if the 32 bit is set. If it is not set, the work is deemed done. Any value in 33-64 inclusive has it set, and gets shifted an extra 32, via mov and xor. Any value in 0-31 has it clear, done. The case of 32 exactly works with the first two instructions. I guess. I didn't come up with this, it is in the AMD optimization manual. wierdo shift 32: (no change) 00006CD4: 83 F9 00 cmp ecx,0 00006CD7: 7D 0F jge 00006CE8 00006CD9: F7 D9 neg ecx 00006CDB: 83 F9 20 cmp ecx,20h 00006CDE: 7D 04 jge 00006CE4 00006CE0: D3 EB shr ebx,cl 00006CE2: EB 0B jmp 00006CEF 00006CE4: 33 DB xor ebx,ebx 00006CE6: EB 07 jmp 00006CEF 00006CE8: 83 F9 20 cmp ecx,20h 00006CEB: 7D F7 jge 00006CE4 00006CED: D3 E3 shl ebx,cl 00006CEF: wierdo shift 64: 000071E9: 83 F9 00 cmp ecx,0 000071EC: 7D 1D jge 0000720B 000071EE: F7 D9 neg ecx 000071F0: 83 F9 40 cmp ecx,40h 000071F3: 7D 10 jge 00007205 000071F5: 0F AD F3 shrd ebx,esi,cl 000071F8: D3 EE shr esi,cl 000071FA: F6 C1 20 test cl,20h 000071FD: 74 04 je 00007203 000071FF: 8B DE mov ebx,esi 00007201: 33 F6 xor esi,esi 00007203: EB 19 jmp 0000721E 00007205: 33 DB xor ebx,ebx 00007207: 33 F6 xor esi,esi 00007209: EB 13 jmp 0000721E 0000720B: 83 F9 40 cmp ecx,40h 0000720E: 7D F5 jge 00007205 00007210: 0F A5 DE shld esi,ebx,cl 00007213: D3 E3 shl ebx,cl 00007215: F6 C1 20 test cl,20h 00007218: 74 04 je 0000721E 0000721A: 8B F3 mov esi,ebx 0000721C: 33 DB xor ebx,ebx 0000721E: as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) We might as well first compare to -64 before the negate, same instruction count, more obviously correct. there are a few extra instructions in wierd shift 64, the parts that shift by more than 32 or more than 64 have common pieces that can be shared ("tail merged") and there is a branch to a jmp We should see about optimizing the wierd shift 64 case. A few instructions can easily be saved. From jkrell at elego.de Tue Mar 2 13:59:31 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 13:59:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302125931.619312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 13:59:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove m3_shift64, which for the record was: uint64 __stdcall m3_shift64(uint64 a, int b) { if (b >= 64 || b <= -64) a = 0; else if (b > 0) a <<= b; else if (b < 0) a >>= -b; return a; } _m3_shift64 at 12: 00000000: 55 push ebp 00000001: 8B EC mov ebp,esp 00000003: 8B 4D 10 mov ecx,dword ptr [ebp+10h] 00000006: 8D 41 3F lea eax,[ecx+3Fh] 00000009: 83 F8 7E cmp eax,7Eh 0000000C: 77 1C ja 0000002A 0000000E: 8B 45 08 mov eax,dword ptr [ebp+8] 00000011: 8B 55 0C mov edx,dword ptr [ebp+0Ch] 00000014: 85 C9 test ecx,ecx 00000016: 7E 07 jle 0000001F 00000018: E8 00 00 00 00 call __allshl 0000001D: EB 0F jmp 0000002E 0000001F: 7D 0D jge 0000002E 00000021: F7 D9 neg ecx 00000023: E8 00 00 00 00 call __aullshr 00000028: EB 04 jmp 0000002E 0000002A: 33 C0 xor eax,eax 0000002C: 33 D2 xor edx,edx 0000002E: 5D pop ebp 0000002F: C2 0C 00 ret 0Ch From jay.krell at cornell.edu Tue Mar 2 14:18:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 2 Mar 2010 13:18:52 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100302125229.A8E4B2474001@birch.elegosoft.com> References: <20100302125229.A8E4B2474001@birch.elegosoft.com> Message-ID: roughly the attached, though I know the case/space diff is also there It's pretty hard to find this stuff via cvsweb/changelog/etc..... - Jay > Date: Tue, 2 Mar 2010 13:52:29 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/02 13:52:29 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.i3 Stackx86.m3 > > Log message: > somewhat consolidate shifting code > > no more "binOpWithShiftCount" > > inline all 64bit shifts, even when no constants involved > (constants get inlined better) > > worst cases: > > shift right 64 (from the AMD manual): > 00002217: 0F AD D3 shrd ebx,edx,cl > 0000221A: D3 EA shr edx,cl > 0000221C: F6 C1 20 test cl,20h > 0000221F: 74 04 je 00002225 > 00002221: 8B DA mov ebx,edx > 00002223: 33 D2 xor edx,edx > 00002225: > > shift left 64 (from the AMD manual): > 0000244B: 0F A5 DA shld edx,ebx,cl > 0000244E: D3 E3 shl ebx,cl > 00002450: F6 C1 20 test cl,20h > 00002453: 74 04 je 00002459 > 00002455: 8B D3 mov edx,ebx > 00002457: 33 DB xor ebx,ebx > 00002459: > > Those sequences are quite subtle. > I'm not sure I understand. > Shift by between 32 and 63: > The "wrong" register is shifted, but it is done modulo-32, > so the correct result is had, in the "wrong" register > then the register is moved to its correct place. > That is: > edx:eax << 33 > is straightforwardly, after testing if the shift count is >32: > edx = eax > edx <<= 1 (shift count - 32) > eax = 0 > however the above does the shift before the move, > since the modulo makes it correct: > eax <<= (33 % 32) which is eax <<= 1 > edx = eax > eax = 0 > > The way it detects >=32 is very subtle to me. > It checks if the 32 bit is set. > If it is not set, the work is deemed done. > Any value in 33-64 inclusive has it set, and gets shifted an extra 32, > via mov and xor. > Any value in 0-31 has it clear, done. > The case of 32 exactly works with the first two instructions. > > I guess. > I didn't come up with this, it is in the AMD optimization manual. > > wierdo shift 32: (no change) > 00006CD4: 83 F9 00 cmp ecx,0 > 00006CD7: 7D 0F jge 00006CE8 > 00006CD9: F7 D9 neg ecx > 00006CDB: 83 F9 20 cmp ecx,20h > 00006CDE: 7D 04 jge 00006CE4 > 00006CE0: D3 EB shr ebx,cl > 00006CE2: EB 0B jmp 00006CEF > 00006CE4: 33 DB xor ebx,ebx > 00006CE6: EB 07 jmp 00006CEF > 00006CE8: 83 F9 20 cmp ecx,20h > 00006CEB: 7D F7 jge 00006CE4 > 00006CED: D3 E3 shl ebx,cl > 00006CEF: > > wierdo shift 64: > 000071E9: 83 F9 00 cmp ecx,0 > 000071EC: 7D 1D jge 0000720B > 000071EE: F7 D9 neg ecx > 000071F0: 83 F9 40 cmp ecx,40h > 000071F3: 7D 10 jge 00007205 > 000071F5: 0F AD F3 shrd ebx,esi,cl > 000071F8: D3 EE shr esi,cl > 000071FA: F6 C1 20 test cl,20h > 000071FD: 74 04 je 00007203 > 000071FF: 8B DE mov ebx,esi > 00007201: 33 F6 xor esi,esi > 00007203: EB 19 jmp 0000721E > 00007205: 33 DB xor ebx,ebx > 00007207: 33 F6 xor esi,esi > 00007209: EB 13 jmp 0000721E > 0000720B: 83 F9 40 cmp ecx,40h > 0000720E: 7D F5 jge 00007205 > 00007210: 0F A5 DE shld esi,ebx,cl > 00007213: D3 E3 shl ebx,cl > 00007215: F6 C1 20 test cl,20h > 00007218: 74 04 je 0000721E > 0000721A: 8B F3 mov esi,ebx > 0000721C: 33 DB xor ebx,ebx > 0000721E: > > as to what shift by FIRST(INTEGER) does, I need to check (but notice that wierd shift 32 isn't changed) > We might as well first compare to -64 before the negate, same instruction count, more > obviously correct. > there are a few extra instructions in wierd shift 64, the parts that > shift by more than 32 or more than 64 have common pieces that > can be shared ("tail merged") and there is a branch to a jmp > > We should see about optimizing the wierd shift 64 case. > A few instructions can easily be saved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Tue Mar 2 14:46:23 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:46:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134623.1FB6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:46:23 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: source of the new bits in shift double must a register, can't be memory, so remove two lines that handle the memory case From jkrell at elego.de Tue Mar 2 14:48:49 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:48:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302134849.6DD6B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:48:49 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: 'shift_double_tail' ended up with only one caller -- 'shift_double_ecx' -- inline it here (these are small functions, point is readability, not perf) From jkrell at elego.de Tue Mar 2 14:52:58 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 14:52:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302135258.352D82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 14:52:58 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: some tersification, not sure this is a good idea -- omit types in VAR, initialize in VAR instead of body From jkrell at elego.de Tue Mar 2 15:14:04 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141404.128992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:04 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 TIntN.i3 TWordN.i3 TWordN.m3 Log message: avoid runtime error (range error) in compiler when user shifts by too large of a number leave it as a warning, generate unoptimized code, and let the runtime error occur in user's program From jkrell at elego.de Tue Mar 2 15:14:34 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 2 Mar 2010 15:14:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100302141434.4A5B42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/02 15:14:34 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: whitespace to my liking From jkrell at elego.de Wed Mar 3 10:21:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:21:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092142.7B7862474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it From jkrell at elego.de Wed Mar 3 10:23:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 10:23:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303092303.41FDD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:23:03 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> in zero_n; gcc backend implements it incorrectly and it is never used From jkrell at elego.de Wed Mar 3 12:09:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:09:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303110910.8DB8F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:09:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: extend test case (a bit annoyingly long already) attempting to insert/extract upper bits I haven't yet extended the bit offsets before I get there, this extension already is exhibiting two behaviors that need further investigation, and is therefore not quite as extended as intended (the commenting out of flipA) in the 32bit insert, I get a subrange error if I allow the flipA Perhaps I just don't understand something. in the 64bit insert, I get an error in the backend if I allow flipA and the code looks a little wrong; it is having trouble allocating registers/temps will test with gcc for one thing and with the release branch the 64bit problem doesn't seem to do with 64bits so much as "complex" expressions in function calls (sounds wrong, but no matter, I'll investigate) From jkrell at elego.de Wed Mar 3 12:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303112525.6BFCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: try make it more portable, and now also reduce runtime significantly by removing coverage that should be redundant From jkrell at elego.de Wed Mar 3 12:31:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:31:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303113140.111092474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:31:39 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: more portability, more shrinkage From jkrell at elego.de Wed Mar 3 12:44:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:44:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114404.568562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:44:04 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: more portable From jkrell at elego.de Wed Mar 3 12:45:45 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:45:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114545.5705C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:45:45 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: -lp and -less-portable synonyms for -'include-less-portable-output From jkrell at elego.de Wed Mar 3 12:47:03 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:47:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114703.EA9F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:47:03 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:48:42 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:48:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303114842.EAA0B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:48:42 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: add little endian 64bit output From jkrell at elego.de Wed Mar 3 12:54:37 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:54:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115437.4B8842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:54:37 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 12:56:40 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 12:56:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303115640.C3CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 12:56:40 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: slightly more debuggable From jkrell at elego.de Wed Mar 3 13:05:53 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:05:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120553.8364B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:05:53 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm-little_endian32 Log message: store result in INTEGER instead of CARDINAL to fix the one problem From jkrell at elego.de Wed Mar 3 13:08:22 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:08:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303120822.1E66F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:08:22 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update amd64 output From jkrell at elego.de Wed Mar 3 13:10:35 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:10:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121035.627AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:10:35 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: add ASSERT FALSE after a new problem test p227 finds if you enable flipA in the LONGINT part of TestInsert From jkrell at elego.de Wed Mar 3 13:14:55 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:14:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121455.71FC02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:14:55 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Main.m3 Log message: don't bother printing the 0 cases that we an just assert: wow that cuts things down! From jkrell at elego.de Wed Mar 3 13:17:10 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:17:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121710.A2D102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:17:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: oops From jkrell at elego.de Wed Mar 3 13:18:09 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:18:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121809.298F12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:18:09 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: update (was small because of assertion failure, alas) From jkrell at elego.de Wed Mar 3 13:19:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 13:19:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303121956.76C162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 13:19:56 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm-little_endian32 Log message: update output From jkrell at elego.de Wed Mar 3 14:11:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 3 Mar 2010 14:11:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303131128.2F6D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 14:11:27 Modified files: cm3/m3-sys/m3front/src/misc/: Tag: release_branch_cm3_5_8 CG.m3 Log message: untested port small fix from head for initializing longint, see revision 1.34 From hosking at cs.purdue.edu Wed Mar 3 16:57:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 10:57:32 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100303092142.7B7862474001@birch.elegosoft.com> References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 3 17:02:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 11:02:36 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com> Message-ID: Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/03 10:21:42 >> >> Modified files: >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> >> Log message: >> zero_n is incorrect and never used, put gcc_assert(0) in it > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Wed Mar 3 17:44:58 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:44:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164458.6DE562474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:44:58 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Detangle spaghetti code: flags are evil! Verbosity is sometimes the essence of clarity when it permits context-freedom. From hosking at elego.de Wed Mar 3 17:49:28 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:49:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303164928.7B6322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:49:28 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Make it compile! From hosking at elego.de Wed Mar 3 17:53:51 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 17:53:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303165351.7B4F02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 17:53:51 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Reorganise slightly so diffs work more nicely with past versions. From hosking at elego.de Wed Mar 3 18:23:21 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:23:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172321.4EEC52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:23:21 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Let's respect the definition of BYTESIZE (in case it ever were to change). Also, why the nasty constant folding in index_address? Let gcc's constant folders take care of it (inside m3_build2). From hosking at elego.de Wed Mar 3 18:24:14 2010 From: hosking at elego.de (Antony Hosking) Date: Wed, 3 Mar 2010 18:24:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100303172415.06D6C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/03 18:24:14 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Fix warning. From jay.krell at cornell.edu Thu Mar 4 00:45:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Mar 2010 23:45:06 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Thu Mar 4 04:15:49 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 4 Mar 2010 4:15:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304031550.08E012474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/04 04:15:49 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Cleanup. Fix m3cg_zero_n. From hosking at cs.purdue.edu Thu Mar 4 04:29:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Mar 2010 22:29:04 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , Message-ID: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:31:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:31:32 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote:Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote:CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 07:46:53 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 01:46:53 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 07:57:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 06:57:14 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> , <0C025143-AB34-4BE8-AD99-17ABC6CAAAA0@cs.purdue.edu> Message-ID: It is still not possible to test. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Thu, 4 Mar 2010 01:46:53 -0500 CC: m3commit at elegosoft.com To: jay.krell at cornell.edu I think I fixed it. On 4 Mar 2010, at 01:31, Jay K wrote: Maybe remove it instead? Unused suggests untested, not working. From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 22:29:04 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 It turns out not actually to be used by m3front. But it is defined by m3middle, so let's support it and not get bitten in the arse if/when m3front ever uses it. On 3 Mar 2010, at 18:45, Jay K wrote: I don't see where it is used. I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> (in m3back). The parameters are being passed to memset in the wrong order. Compare it to m3cg_zero. I was actually looking to see if parameters are left to right or right to left, I looked at these two examples and decided they can't both be correct. - Jay From: hosking at cs.purdue.edu Date: Wed, 3 Mar 2010 11:02:36 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Please say how this is broken. On 3 Mar 2010, at 10:57, Tony Hosking wrote: Huh? I see it in the front-end! On 3 Mar 2010, at 10:21, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/03 10:21:42 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: zero_n is incorrect and never used, put gcc_assert(0) in it -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 4 08:16:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 07:16:20 +0000 Subject: [M3commit] m3_build vs. build in parse.c? Message-ID: Why use one vs. the other? It appears that they are equivalent *except* that m3_build attempts to optimize, but falls back to build if it can't. That is, m3_build calls fold_build. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Mar 4 08:58:30 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 4 Mar 2010 02:58:30 -0500 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: References: Message-ID: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. On 4 Mar 2010, at 02:16, Jay K wrote: > Why use one vs. the other? > It appears that they are equivalent *except* that m3_build attempts to optimize, > but falls back to build if it can't. > > That is, m3_build calls fold_build. > > - Jay > > > > From jay.krell at cornell.edu Thu Mar 4 09:46:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 4 Mar 2010 08:46:06 +0000 Subject: [M3commit] m3_build vs. build in parse.c? In-Reply-To: <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> References: , <16ADF5CA-B729-40CC-ADAB-5FA170C9084B@cs.purdue.edu> Message-ID: Why not always call m3_build? Why ever call build? - Jay > From: hosking at cs.purdue.edu > Date: Thu, 4 Mar 2010 02:58:30 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] m3_build vs. build in parse.c? > > So that we can avoid having to analyse all the constants ourselves. We can simply generate the trees and then have gcc fold them. > > On 4 Mar 2010, at 02:16, Jay K wrote: > > > Why use one vs. the other? > > It appears that they are equivalent *except* that m3_build attempts to optimize, > > but falls back to build if it can't. > > > > That is, m3_build calls fold_build. > > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Mar 4 12:43:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 04 Mar 2010 12:43:52 +0100 Subject: [M3commit] lost commit messages: Fwd: 4 Forwarded Messages Message-ID: <20100304124352.acni7mp0nk8k0wk4@mail.elegosoft.com> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:57:48 +0100 Size: 2468 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:55:52 +0100 Size: 2523 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:51:37 +0100 Size: 2452 URL: -------------- next part -------------- An embedded message was scrubbed... From: m3commit-bounces at elegosoft.com Subject: Auto-discard notification Date: Thu, 04 Mar 2010 09:50:37 +0100 Size: 2518 URL: From jkrell at elego.de Thu Mar 4 13:57:24 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 13:57:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304125724.807162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 13:57:24 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: eliminate calls to set_member and set_singleton the unoptimized code for set_member is decent, though not nearly as good as m3back (m3back uses bts and bt) the code for set_singleton never seems particularly great but ok I tried a lot with array_ref, and bit_field ref, no luck the use of stabilize_reference (or build(save_expr)) does help In particular in set_singleton, I can't get the compiler to "or into memory", never as good even when optimized as optimized C. The C compiler's best: void set_singleton(unsigned* a, unsigned b) { a[b / 32] |= (1 << (b % 32)); } pushl %ebp movl %esp, %ebp movl 12(%ebp), %ecx movl 8(%ebp), %eax movl %ecx, %edx andl $31, %ecx shrl $5, %edx leal (%eax,%edx,4), %edx << not able to get this from cm3cg movl $1, %eax sall %cl, %eax orl %eax, (%edx) << not able to get this from cm3cg popl %ebp ret I can never get it to use lea with both a scale and an address. I will try a bit more, but this version should do. In particular I was using bit_field_ref with size 1, setting it to 1, maybe a full word will work better. This variation also has an advantage over some in that it shouldn't break pickles. This might be considered a significant size deoptimization and better off before, calling a function. tested on LINUXLIBC6 (so far) From jkrell at elego.de Thu Mar 4 14:19:06 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 14:19:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304131906.E94622474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 14:19:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove set_singleton and set_member From jkrell at elego.de Thu Mar 4 15:41:22 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 15:41:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304144122.CF96B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 15:41:22 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: stylistic variation on previous From rodney_bates at lcwb.coop Thu Mar 4 21:45:12 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 04 Mar 2010 14:45:12 -0600 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu> Message-ID: <4B901BD8.10403@lcwb.coop> Jay K wrote: > Maybe remove it instead? Unused suggests untested, not working. I am with Tony on this one. Well-designed code has always had places where it will handle a more general input space than current use-cases demand. Always removing everything from what is handled reflects the view that a program is a one-time thing that never changes. Putting in some things that follow a consistent general pattern reflects the view that a program is an evolving thing. Excepting a very few programs that are either trivial or very little-used, the latter assumption is always the correct one. Of course, you can't put everything imaginable in. But things that are part of a general pattern are good candidates. Nobody could _ever_ design very useful code, if not following this principal. I once, in my very first job, had to rework a big test driver written in such a way that it handled exactly the set of test cases that had been originally specified and not a thing more. Nobody could add any new cases as things evolved. The internal structure bore no resemblance to the pattern of the inputs. I could only throw it all out except for some low-level routines and start over. > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 22:29:04 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > It turns out not actually to be used by m3front. But it is defined by > m3middle, so let's support it and not get bitten in the arse if/when > m3front ever uses it. > > On 3 Mar 2010, at 18:45, Jay K wrote: > > I don't see where it is used. > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > (in m3back). > The parameters are being passed to memset in the wrong order. > Compare it to m3cg_zero. > I was actually looking to see if parameters are left to right or > right to left, I looked at these two examples and decided they can't > both be correct. > > - Jay > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Wed, 3 Mar 2010 11:02:36 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > Please say how this is broken. > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > Huh? I see it in the front-end! > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/03 10:21:42 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > From jkrell at elego.de Thu Mar 4 23:50:37 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:50:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225038.01F032474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:50:37 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: go a back a version to 1.88 From jkrell at elego.de Thu Mar 4 23:52:57 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 4 Mar 2010 23:52:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100304225257.BA75F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/04 23:52:57 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: back to versoin 1.123 pending more testing From jay.krell at cornell.edu Fri Mar 5 01:50:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 00:50:28 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100304225257.BA75F2474001@birch.elegosoft.com> References: <20100304225257.BA75F2474001@birch.elegosoft.com> Message-ID: This was probably fine. I had a failure on a machine but that was possibly some uncommited version. I also had some version go through ok on LINUXLIBC6 and some version on AMD64_DARWIN so the approach is ok. To be certain I reverted it for now. Will probably back something within 24 hours. I'll maybe test SOLgnu and PPC_DARWIN as well. - Jay ---------------------------------------- > Date: Thu, 4 Mar 2010 23:52:57 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/04 23:52:57 > > Modified files: > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > Log message: > back to versoin 1.123 pending more testing > From jkrell at elego.de Fri Mar 5 11:25:21 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 11:25:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305102521.7CBCE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 11:25:21 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: cm3cfg.common Log message: small workaround wrt M3_PROFILING for older cm3 and/or other m3quake users other than cm3 From jkrell at elego.de Fri Mar 5 12:16:49 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:16:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305111649.CD4AF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:16:49 Modified files: cm3/scripts/python/: pylib.py Log message: don't put mklib in boot archives just because the overly simple makefile can only link one executable; don't include --32 on PPC_LINUX assembler invocations, it doesn't like it From jkrell at elego.de Fri Mar 5 12:56:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 12:56:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305115628.4F8B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 12:56:28 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: PPC64_DARWIN Log message: 'PPC.common' => 'PPC64.common' From jkrell at elego.de Fri Mar 5 13:19:02 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:19:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305121902.4D7792474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:19:02 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Log message: #if __APPLE__ && __x86_64__ => __APPLE__ && __LP64__ so that is also works on PPC64 From jkrell at elego.de Fri Mar 5 13:45:27 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:45:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124527.D0EA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:45:27 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: again: remove set_member and set_singleton From jkrell at elego.de Fri Mar 5 13:48:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:48:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305124817.C66CB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:48:17 Modified files: cm3/scripts/python/: pylib.py Log message: add -arch ppc64 on PPC64_DARWIN, like -arch x86_64 on AMD64_DARWIN From jkrell at elego.de Fri Mar 5 13:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125132.72FE32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:51:32 Modified files: cm3/m3-libs/m3core/src/atomic/: m3makefile Log message: Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. The first two platforms fail to link due to references to these functions. Presumably the last too. I know the plan is to fallback to locks somewhere, but I don't think they have materialized yet. From jkrell at elego.de Fri Mar 5 13:53:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:53:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125358.707872474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:53:58 Modified files: cm3/m3-libs/m3core/src/runtime/POSIX/: RTSignalC.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. From jkrell at elego.de Fri Mar 5 13:54:44 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:54:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125444.8D6CE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:54:44 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadApple.c Log message: #define __DARWIN_UNIX03 0 This fixes my PPC64 system and is probably the right general fix for the nagging 10.4 (and earlier?) problems. (same problem and fix as RTSignalC.c) From jkrell at elego.de Fri Mar 5 13:57:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 13:57:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305125712.A4F8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 13:57:12 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: m3makefile Removed files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadInterix.c Log message: not used: ThreadInterix.c From jkrell at elego.de Fri Mar 5 14:09:39 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:09:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305130939.75E332474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:09:39 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: decrease PPC_DARWIN jmpbuf align to 32 add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:11:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:11:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131147.559DB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:11:47 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: slightly different style From jkrell at elego.de Fri Mar 5 14:16:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:16:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131629.36D552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:16:29 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Compiler.tmpl Log message: add PPC64_DARWIN From jkrell at elego.de Fri Mar 5 14:17:13 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 14:17:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305131713.EB0262474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 14:17:13 Modified files: cm3/m3-libs/libm3/src/: platforms.quake Log message: add PPC64_DARWIN (only needed for cross builds I believe, but that's what I did so far) From jay.krell at cornell.edu Fri Mar 5 14:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 13:57:24 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <4B901BD8.10403@lcwb.coop> References: <20100303092142.7B7862474001@birch.elegosoft.com>, ,,, , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I understand that. I often am "like that". But we are our own consumers. The code has probably been unused a long time, but I didn't check. We can put it in when we need it. http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it - Jay > Date: Thu, 4 Mar 2010 14:45:12 -0600 > From: rodney_bates at lcwb.coop > To: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > Jay K wrote: > > Maybe remove it instead? Unused suggests untested, not working. > > I am with Tony on this one. Well-designed code has always had places where > it will handle a more general input space than current use-cases demand. > > Always removing everything from what is handled reflects the view that a > program is a one-time thing that never changes. Putting in some things > that follow a consistent general pattern reflects the view that a program > is an evolving thing. Excepting a very few programs that are either trivial > or very little-used, the latter assumption is always the correct one. > > Of course, you can't put everything imaginable in. But things that are part > of a general pattern are good candidates. Nobody could _ever_ design very > useful code, if not following this principal. > > I once, in my very first job, had to rework a big test driver written in > such a way that it handled exactly the set of test cases that had been > originally specified and not a thing more. Nobody could add any new cases > as things evolved. The internal structure bore no resemblance to the > pattern of the inputs. I could only throw it all out except for some > low-level routines and start over. > > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > It turns out not actually to be used by m3front. But it is defined by > > m3middle, so let's support it and not get bitten in the arse if/when > > m3front ever uses it. > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > I don't see where it is used. > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > (in m3back). > > The parameters are being passed to memset in the wrong order. > > Compare it to m3cg_zero. > > I was actually looking to see if parameters are left to right or > > right to left, I looked at these two examples and decided they can't > > both be correct. > > > > - Jay > > > > ------------------------------------------------------------------------ > > From: hosking at cs.purdue.edu > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > To: hosking at cs.purdue.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Please say how this is broken. > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > Huh? I see it in the front-end! > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > Modified files: > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > Log message: > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 15:12:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:12:55 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305125132.72FE32474001@birch.elegosoft.com> References: <20100305125132.72FE32474001@birch.elegosoft.com> Message-ID: I think PPC has the necessary instructions. Does gcc not generate them? Maybe need a -arch parameter to get it to use them. On 5 Mar 2010, at 13:51, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/05 13:51:32 > > Modified files: > cm3/m3-libs/m3core/src/atomic/: m3makefile > > Log message: > Remove atomic Longint for now on PPC_LINUX, PPC_DARWIN, PPC32_OPENBSD. > The first two platforms fail to link due to references to these > functions. Presumably the last too. I know the plan is to fallback to > locks somewhere, but I don't think they have materialized yet. From hosking at elego.de Fri Mar 5 15:16:38 2010 From: hosking at elego.de (Antony Hosking) Date: Fri, 5 Mar 2010 15:16:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305141638.827582474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/05 15:16:38 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: Cleaner! From hosking at cs.purdue.edu Fri Mar 5 15:17:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 09:17:21 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100303092142.7B7862474001@birch.elegosoft.com>, , , , , , , , , , <4A6C5113-F5F2-4E7A-94B6-82A623A9554E@cs.purdue.edu>, , <4B901BD8.10403@lcwb.coop> Message-ID: I already fixed it! On 5 Mar 2010, at 08:57, Jay K wrote: > I understand that. I often am "like that". > But we are our own consumers. The code has probably been unused a long time, but I didn't check. > We can put it in when we need it. > http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it > > > - Jay > > > > Date: Thu, 4 Mar 2010 14:45:12 -0600 > > From: rodney_bates at lcwb.coop > > To: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > Jay K wrote: > > > Maybe remove it instead? Unused suggests untested, not working. > > > > I am with Tony on this one. Well-designed code has always had places where > > it will handle a more general input space than current use-cases demand. > > > > Always removing everything from what is handled reflects the view that a > > program is a one-time thing that never changes. Putting in some things > > that follow a consistent general pattern reflects the view that a program > > is an evolving thing. Excepting a very few programs that are either trivial > > or very little-used, the latter assumption is always the correct one. > > > > Of course, you can't put everything imaginable in. But things that are part > > of a general pattern are good candidates. Nobody could _ever_ design very > > useful code, if not following this principal. > > > > I once, in my very first job, had to rework a big test driver written in > > such a way that it handled exactly the set of test cases that had been > > originally specified and not a thing more. Nobody could add any new cases > > as things evolved. The internal structure bore no resemblance to the > > pattern of the inputs. I could only throw it all out except for some > > low-level routines and start over. > > > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 22:29:04 -0500 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > It turns out not actually to be used by m3front. But it is defined by > > > m3middle, so let's support it and not get bitten in the arse if/when > > > m3front ever uses it. > > > > > > On 3 Mar 2010, at 18:45, Jay K wrote: > > > > > > I don't see where it is used. > > > I built all of "std" with the gcc_assert(0) and <* ASSERT FALSE *> > > > (in m3back). > > > The parameters are being passed to memset in the wrong order. > > > Compare it to m3cg_zero. > > > I was actually looking to see if parameters are left to right or > > > right to left, I looked at these two examples and decided they can't > > > both be correct. > > > > > > - Jay > > > > > > ------------------------------------------------------------------------ > > > From: hosking at cs.purdue.edu > > > Date: Wed, 3 Mar 2010 11:02:36 -0500 > > > To: hosking at cs.purdue.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > Please say how this is broken. > > > > > > On 3 Mar 2010, at 10:57, Tony Hosking wrote: > > > > > > Huh? I see it in the front-end! > > > > > > > > > On 3 Mar 2010, at 10:21, Jay Krell wrote: > > > > > > CVSROOT: /usr/cvs > > > Changes by: jkrell at birch. 10/03/03 10:21:42 > > > > > > Modified files: > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > > > > Log message: > > > zero_n is incorrect and never used, put gcc_assert(0) in it > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 15:34:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:34:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305143429.4B9522474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:34:29 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: oops I was fiddling with bytes and bits and how to annotate them and I got it wrong: alignment is 32, 32 bits From jkrell at elego.de Fri Mar 5 15:46:40 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:46:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305144640.E147F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:46:40 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: no ODBC on PPC64_DARWIN From jkrell at elego.de Fri Mar 5 15:51:47 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 15:51:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305145148.851592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 15:51:47 Modified files: cm3/scripts/python/: pylib.py Log message: detect PPC64_DARWIN, from 32bit Python, by comparing ppc970 to ppc970 From jkrell at elego.de Fri Mar 5 16:00:35 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:00:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150035.B69F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:00:35 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: PPC64_DARWIN 10.4: no X, no Trestle: we need to teach cm3 to sniff the directories/files and their architectures From jkrell at elego.de Fri Mar 5 16:06:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:06:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150658.81EB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:06:58 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:09:19 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:09:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305150919.85D9E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:09:19 Modified files: cm3/m3-sys/cminstall/src/config-no-install/: Darwin.common Log message: oops From jkrell at elego.de Fri Mar 5 16:16:15 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:16:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305151615.2DEEA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:16:15 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: fix typo, so it works on big endian systems, such as PPC64_DARWIN (and PPC_DARWIN, PPC_LINUX, SOLgnu, SPARC32_LINUX, etc.) From jkrell at elego.de Fri Mar 5 16:22:06 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:22:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152206.117CC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:22:06 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian64 Log message: replace portable output with correct output From jkrell at elego.de Fri Mar 5 16:25:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 16:25:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305152514.247902474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 16:25:14 Added files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm32 stdout.pgm64 Removed files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm-little_endian32 stdout.pgm-little_endian64 Log message: it turns out this isn't (currently) endian specific, just wordsize specific (PPC64_DARWIN output matches AMD64_DARWIN) From jay.krell at cornell.edu Fri Mar 5 16:32:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Mar 2010 15:32:00 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100305141638.827582474001@birch.elegosoft.com> References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear I suppose for alignment I could say bits = 1. - Jay > Date: Fri, 5 Mar 2010 15:16:38 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/05 15:16:38 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > Cleaner! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Mar 5 17:11:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 5 Mar 2010 11:11:41 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100305141638.827582474001@birch.elegosoft.com> Message-ID: <343D34B0-D380-4FEF-AD8B-B2DB03E6A8F3@cs.purdue.edu> Why not multiply by some appropriate size. x * Int32.size, etc.? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 5 Mar 2010, at 10:32, Jay K wrote: > sorry; mine was just wrong I'd say; in the one case wrong, in the other case completely unclear > I suppose for alignment I could say bits = 1. > > - Jay > > > > Date: Fri, 5 Mar 2010 15:16:38 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/05 15:16:38 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: Target.m3 > > > > Log message: > > Cleaner! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Fri Mar 5 22:11:26 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:11:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211126.9928B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:11:26 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: do it the usual way: * Word8.size; Word32.size From jkrell at elego.de Fri Mar 5 22:17:29 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:17:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211729.31D422474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:17:29 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertToCygwinPath' => 'ConvertToCygwinPath' (private to public) so that make-dist.py works From jkrell at elego.de Fri Mar 5 22:18:48 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 5 Mar 2010 22:18:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100305211848.6ABD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/05 22:18:48 Modified files: cm3/scripts/python/: pylib.py Log message: '_ConvertFromCygwinPath' => 'ConvertFromCygwinPath' (private to public) just to match ConvertToCygwinPath (not used) From jkrell at elego.de Sat Mar 6 12:02:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:02:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306110201.94DED2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:02:01 Added files: cm3/m3-sys/m3tests/src/p2/p231/: m3makefile Main.m3 Log message: small test case split out of p227 that shows something m3back currently fails to compile From jkrell at elego.de Sat Mar 6 12:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306111830.94AB42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:18:30 Added files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm-big_endian stdout.pgm-little_endian Removed files: cm3/m3-sys/m3tests/src/p2/p230/: stdout.pgm Log message: big endian output (and really we have to compare this with an older compiler, make sure replacement of set_singleton hasn't changed which bits are set -- pickle compatibility) From jkrell at elego.de Sat Mar 6 12:23:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:23:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112338.8F4482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:23:38 Removed files: cm3/m3-sys/m3tests/src/p2/p225/: stderr.build stdout.build stderr.pgm Log message: shouldn't need the zero sized files any longer From jkrell at elego.de Sat Mar 6 12:26:29 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 12:26:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306112629.ED4102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 12:26:29 Modified files: cm3/m3-sys/m3tests/src/p2/p231/: Main.m3 Log message: comment as to what the test is for From jkrell at elego.de Sat Mar 6 13:38:38 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:38:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306123838.6C3B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:38:38 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: some cleanup ahead of other fixes (the free_temp problem) in particular: - replace RegSet{} with AllRegisters This makes some code a little simpler. RegSet{} does mean "anything" and we can capture that pretty faithfully via AllRegisters. We are lucky we don't have to allocate float registers though, that might call for something a little different - in some places I was extra cautious and ran the same old code for size = 1 (data fitting in a single register), as well there are places that assume the largest size is 2 Generalize *some* of that to loop over whatever size, doing the "same" thing at each step. There are still places that say like "if foo[0] and foo[size - 1]" which works as long as size can only be 1 or 2. - fix warning about unreachable code after assert false (the unused, untested zero_n) From jay.krell at cornell.edu Sat Mar 6 13:39:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:39:41 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306123838.6C3B22474001@birch.elegosoft.com> References: <20100306123838.6C3B22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 6 Mar 2010 13:38:38 +0000 > To: m3commit > From: jkrell > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:38:38 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > some cleanup ahead of other fixes (the free_temp problem) > > in particular: > - replace RegSet{} with AllRegisters > This makes some code a little simpler. > RegSet{} does mean "anything" and we can > capture that pretty faithfully via AllRegisters. > We are lucky we don't have to allocate float registers though, > that might call for something a little different > > - in some places I was extra cautious and ran > the same old code for size = 1 (data fitting in a single register), > as well there are places that assume the largest size is 2 > Generalize *some* of that to loop over whatever size, doing > the "same" thing at each step. > > There are still places that say like "if foo[0] and foo[size - 1]" > which works as long as size can only be 1 or 2. > > - fix warning about unreachable code after assert false (the unused, > untested zero_n) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 6 13:55:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 6 Mar 2010 13:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100306125552.552592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/06 13:55:52 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 only call free_temp for operandPart = 0 Better might be to, like, remove some/many of the loops and teach more of the code to deal with "multi part operands" (or multi register operands). From jay.krell at cornell.edu Sat Mar 6 13:56:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Mar 2010 12:56:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100306125552.552592474001@birch.elegosoft.com> References: <20100306125552.552592474001@birch.elegosoft.com> Message-ID: very small diff inline: Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.112 diff -u -r1.112 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:38:38 -0000 1.112 +++ Stackx86.m3 6 Mar 2010 12:54:37 -0000 @@ -197,7 +197,9 @@ IF op.loc = OLoc.mem THEN IF op.mvar.var.stack_temp THEN - t.parent.free_temp(op.mvar.var); + IF operandPart = 0 THEN + t.parent.free_temp(op.mvar.var); + END; ELSE t.reguse[r].last_store := op.mvar; END > Date: Sat, 6 Mar 2010 13:55:52 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/06 13:55:52 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > very small but slightly fragile fix for m3-sys\m3tests\src\p2\p231 > only call free_temp for operandPart = 0 > > Better might be to, like, remove some/many of the loops and > teach more of the code to deal with "multi part operands" > (or multi register operands). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 7 03:32:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:32:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023243.806FA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:32:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: 'ulong' => 'size_t' where it is easy (more coming) From jkrell at elego.de Sun Mar 7 03:33:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:33:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023327.12FAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:33:26 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove check for older Microsoft compiler with no __int64 support (16bit compiler) From jkrell at elego.de Sun Mar 7 03:34:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:34:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023450.6F4212474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:34:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: assume but verify that uint is 32bits From jkrell at elego.de Sun Mar 7 03:35:31 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:35:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023531.EEFAF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:35:31 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add comment From jkrell at elego.de Sun Mar 7 03:37:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:37:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307023704.88E182474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:37:04 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: maybe a safer check, in case of overflow From jkrell at elego.de Sun Mar 7 03:47:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:47:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307024743.D13762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:47:42 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: this part of the test is 32bit specific From jkrell at elego.de Sun Mar 7 03:54:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 3:54:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307025406.5C6C92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 03:54:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'ulong' => 'size_t' (much of this going away shortly) From jkrell at elego.de Sun Mar 7 04:01:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:01:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030112.BA0DA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:01:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: more 'size_t' => 'ulong' to fix gcc printf warnings From jkrell at elego.de Sun Mar 7 04:06:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:06:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307030630.9093B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:06:30 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: collect timings on other platforms, albeit low resolution From jkrell at elego.de Sun Mar 7 04:20:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:20:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032021.E1DFF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:20:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: replace set_range with set_range_new set_range_new is never significantly slower and sometimes significantly faster, depending on architecture, compiler, optimization flags optimization definitely helps this code a lot sometimes, e.g. old is 9 seconds unoptimized on sparc64, new is 3 seconds unoptimized they are both 26 seconds we should probably use #pragmas to ensure it is optimized Still have NT386 tables, to be removed soon. From jkrell at elego.de Sun Mar 7 04:21:47 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:21:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032148.A06B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:21:47 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ulong typedef is unused now, remove it From jkrell at elego.de Sun Mar 7 04:24:20 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:24:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032420.9D4112474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:24:20 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove all the "not yet" stuff I put in recently: math with overflow checking I still think we might do something like this, though we can probably write it just as well in Modula-3, if not get the compiler to give us the carry flag (certainly m3back can do better) Anyway, we can recover it from here if needed. From jay.krell at cornell.edu Sun Mar 7 04:24:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:24:46 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032420.9D4112474001@birch.elegosoft.com> References: <20100307032420.9D4112474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:24:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:24:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > Log message: > remove all the "not yet" stuff I put in recently: math with overflow checking > I still think we might do something like this, though > we can probably write it just as well in Modula-3, > if not get the compiler to give us the carry flag (certainly > m3back can do better) > Anyway, we can recover it from here if needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:26:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032619.2B77B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:26:19 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: again remove set_member and set_singleton: neither backend references them any longer From jkrell at elego.de Sun Mar 7 04:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032706.2E8CD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:27:06 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove #define of __fastcall, unused From jkrell at elego.de Sun Mar 7 04:28:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:28:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307032816.7237A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:28:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put _lowbits, _highbits under #ifdef _WIN32; m3back uses them for insert/extract; they will go away soon anyway From jay.krell at cornell.edu Sun Mar 7 04:20:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 03:20:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307032021.E1DFF2474001@birch.elegosoft.com> References: <20100307032021.E1DFF2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 04:20:20 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 04:20:20 > > Modified files: > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c > > Log message: > replace set_range with set_range_new > set_range_new is never significantly slower and sometimes significantly faster, > depending on architecture, compiler, optimization flags > optimization definitely helps this code a lot sometimes, e.g. > old is 9 seconds unoptimized on sparc64, new is 3 seconds > unoptimized they are both 26 seconds > we should probably use #pragmas to ensure it is optimized > > Still have NT386 tables, to be removed soon. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 04:32:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:32:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033246.0A6542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:32:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the old div and mod functions put the current 64bit div and mod under #ifdef _WIN32 gcc backend no longer references any div/mod functions and m3back only does so for 64bit longint (at least for now) From jkrell at elego.de Sun Mar 7 04:33:48 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:33:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033348.D46452474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:33:48 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove very old 'crash' function that has been sitting here commented out for years From jkrell at elego.de Sun Mar 7 04:35:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:35:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033535.3006B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:35:34 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define WIN32_STATIC From jkrell at elego.de Sun Mar 7 04:36:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033619.C8A202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove unused #define INT64_MIN, INT64_MAX, they probably went with the math with overflow checking functions From jkrell at elego.de Sun Mar 7 04:36:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:36:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307033651.042102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:36:50 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: oops: the new set_range must not be static From jkrell at elego.de Sun Mar 7 04:49:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:49:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307034944.02C542474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:49:43 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove whitespace from ends of lines From jkrell at elego.de Sun Mar 7 04:50:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 4:50:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307035015.D283F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 04:50:15 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: restore INT64_MIN, INT64_MAX (test code only) From jkrell at elego.de Sun Mar 7 05:37:51 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:37:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307043751.99BB92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:37:51 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: demonstrate the formula m3back uses for more efficient bit extraction it is x86 specific in that shift counts are treated mod 32 and it doesn't work for extracting zero bits, we should check that we are never asked for that From jkrell at elego.de Sun Mar 7 05:45:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 5:45:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307044521.881992474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 05:45:21 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: don't allow extracting and sign extending zero bits From jay.krell at cornell.edu Sun Mar 7 05:46:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 04:46:05 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307044521.881992474001@birch.elegosoft.com> References: <20100307044521.881992474001@birch.elegosoft.com> Message-ID: small diff attached/inline Index: Stackx86.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3back/src/Stackx86.m3,v retrieving revision 1.113 diff -u -r1.113 Stackx86.m3 --- Stackx86.m3 6 Mar 2010 12:55:52 -0000 1.113 +++ Stackx86.m3 7 Mar 2010 04:42:39 -0000 @@ -1641,6 +1641,15 @@ really messy to cover all the special cases correctly *) IF sign THEN + + (* The method used here does not work for extracting zero bits. + * Make sure we are not asked to do that. + *) + IF NOT (stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero)) THEN + t.Err("doextract: not able to extract and sign extend zero bits"); + END; + <* ASSERT stop2.loc = OLoc.imm AND TIntN.NE(stop2.imm, TZero) *> + find(t, stack0, Force.regset, RegSet { ECX }); find(t, stack1, Force.any); find(t, stack2, Force.anyreg); > Date: Sun, 7 Mar 2010 05:45:21 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 05:45:21 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > don't allow extracting and sign extending zero bits > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 07:38:12 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:38:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307063812.61BC82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:38:12 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: put back assertions, until I verify there are separate runtime checks; put uint32 check and typedef next to each other From jkrell at elego.de Sun Mar 7 07:40:53 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:40:53 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064053.7CE822474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:40:53 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: move #define I64 from hand.c to test_hand.c From jkrell at elego.de Sun Mar 7 07:47:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:47:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064702.607B12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:47:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove the insert/extract64 functions from non-Windows builds From jkrell at elego.de Sun Mar 7 07:48:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:48:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064855.0D38C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:48:54 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: fix indentation of set_range From jkrell at elego.de Sun Mar 7 07:49:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 7:49:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307064932.6667C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 07:49:32 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: ~0UL => ~(size_t)0 From jkrell at elego.de Sun Mar 7 08:09:37 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 8:09:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307070937.AF9B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 08:09:37 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 Log message: put ASSERT FALSE after every error Also this way I don't have to repeat every condition. From jay.krell at cornell.edu Sun Mar 7 08:10:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 07:10:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307070937.AF9B92474001@birch.elegosoft.com> References: <20100307070937.AF9B92474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 08:09:37 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 08:09:37 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 Stackx86.m3 > > Log message: > put ASSERT FALSE after every error > Also this way I don't have to repeat every condition. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 09:31:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 9:31:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307083125.E71382474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 09:31:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: make procedure find a little more conservative with regard to the 64bit longint changes in particular, don't change the 'set' variable, instead: - in[i] := inreg(t, opA[i].mvar, set); - IF size > 1 THEN - set := set - RegSet{in[i]}; + IF i = 0 THEN + in[i] := inreg(t, opA[i].mvar, set); + ELSE + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); END; (though I was hoping to remove the assumption that size <= 2, I have increased) put procedure pushnew1 and procedure pushnew back together as one procedure, with loops inside it it kind of looks like otherwise might have e.g. saved stuff to two temporary variables instead of one rename procedure maybe_expand_stack to expand_stack it still only expands the stack sometimes, but I think the name is adequate eliminate unnecessary variable 'size' in procedure discard some whitespace/commenting changes From jay.krell at cornell.edu Sun Mar 7 09:38:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 08:38:07 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307083125.E71382474001@birch.elegosoft.com> References: <20100307083125.E71382474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sun, 7 Mar 2010 09:31:25 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 09:31:25 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > make procedure find a little more conservative > with regard to the 64bit longint changes > in particular, don't change the 'set' variable, > instead: > > - in[i] := inreg(t, opA[i].mvar, set); > - IF size > 1 THEN > - set := set - RegSet{in[i]}; > + IF i = 0 THEN > + in[i] := inreg(t, opA[i].mvar, set); > + ELSE > + in[i] := inreg(t, opA[i].mvar, set - RegSet{in[0]}); > END; > > (though I was hoping to remove the assumption that size <= 2, I have increased) > > put procedure pushnew1 and procedure pushnew back together as > one procedure, with loops inside it > it kind of looks like otherwise might have e.g. saved stuff to two temporary variables > instead of one > > rename procedure maybe_expand_stack to expand_stack > it still only expands the stack sometimes, but I think the name is adequate > > eliminate unnecessary variable 'size' in procedure discard > > some whitespace/commenting changes > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 10:15:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:15:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091540.25EEF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:15:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091840.E254B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:40 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 10:18:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 10:18:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307091854.484B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 10:18:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Log message: 'sign' => 'sign_extend' From jkrell at elego.de Sun Mar 7 12:11:54 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 12:11:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307111154.C02122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 12:11:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: correct and increase restrictions on extract parameters n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) if sign_extend, then must be constant and > 1 There is historical code for dealing with non-constant n and sign extension, and it is apparently clever and correct, except it doesn't work for n = 0. If we need this to work better, we could insert a runtime check for n = 0, or use code that handles 0 (see hand.c, at least for now). Word/Long do not expose extract with sign extension. The option is available only to m3back clients, ie. m3front, and it's not hard to imagine that the number of bits it wants is always constant and never 0. From jay.krell at cornell.edu Sun Mar 7 12:16:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 11:16:03 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307111154.C02122474001@birch.elegosoft.com> References: <20100307111154.C02122474001@birch.elegosoft.com> Message-ID: attached > Date: Sun, 7 Mar 2010 12:11:54 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 12:11:54 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > correct and increase restrictions on extract parameters > n and m if constant must be positive (they should probably be CARDINAL or 0..63 instead of INTEGER) > if sign_extend, then must be constant and > 1 > > There is historical code for dealing with non-constant n and sign extension, > and it is apparently clever and correct, except it doesn't work for n = 0. > If we need this to work better, we could insert a runtime check for n = 0, > or use code that handles 0 (see hand.c, at least for now). > > Word/Long do not expose extract with sign extension. > The option is available only to m3back clients, ie. m3front, > and it's not hard to imagine that the number of bits it wants > is always constant and never 0. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:03:26 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:03:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307120326.C3A742474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:03:26 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove commented out code regarding bin_use and lib_use (which don't exist) From jkrell at elego.de Sun Mar 7 13:13:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:13:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307121318.8535A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:13:18 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: make -no-m3ship-resolution work in more circumstances, such as when environment variable CM3_INSTALL has forward slashes, on Windows. Note that we now break -no-m3ship-resolution in the unusual case of a Posix user using \ as a "normal" path character. I consider that highly unlikely, however if needed, there are other solutions here. From jay.krell at cornell.edu Sun Mar 7 13:14:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 12:14:08 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307121318.8535A2474001@birch.elegosoft.com> References: <20100307121318.8535A2474001@birch.elegosoft.com> Message-ID: diff attached - Jay > Date: Sun, 7 Mar 2010 13:13:18 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 13:13:18 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > make -no-m3ship-resolution work in more circumstances, such > as when environment variable CM3_INSTALL has forward slashes, > on Windows. > Note that we now break -no-m3ship-resolution in the unusual > case of a Posix user using \ as a "normal" path character. > I consider that highly unlikely, however if needed, there > are other solutions here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 7 13:39:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:39:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307123914.717A22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:39:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: <* ASSERT FALSE *> after ever Err() I thought I had already done this, but I missed a bunch. This way we get a callstack. From jkrell at elego.de Sun Mar 7 13:44:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 13:44:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307124411.AB5D52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 13:44:11 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: wordsmithing/comments: in particular, make it completely obvious to any quick observer which code is commented out, by putting * at the start of every line From jkrell at elego.de Sun Mar 7 15:12:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:12:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141218.728F62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! From jkrell at elego.de Sun Mar 7 15:17:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 7 Mar 2010 15:17:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307141745.C5E312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:17:45 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 Log message: further narrow down extract to what m3front uses and we can therefore test => sign_extend requires constant m and constant n (I'm thinking I should see if the coverage stuff works.. and if not fix it..) stack should handle all 32bit cases inline leaving the function calls only for some 64bit cases (for now) something is fishy here for 64bit + sign extension + non constant m/n will resolve shortly (for now I'm leaving 64bit extract + sign extend + non constant m/n) some newlines for readability From jay.krell at cornell.edu Sun Mar 7 15:18:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 14:18:36 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141745.C5E312474001@birch.elegosoft.com> References: <20100307141745.C5E312474001@birch.elegosoft.com> Message-ID: diff attached.. > Date: Sun, 7 Mar 2010 15:17:45 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:17:45 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.m3 > > Log message: > further narrow down extract to what m3front uses > and we can therefore test > => sign_extend requires constant m and constant n > (I'm thinking I should see if the coverage stuff works.. > and if not fix it..) > > stack should handle all 32bit cases inline > leaving the function calls only for some 64bit cases (for now) > > something is fishy here for 64bit + sign extension + non constant m/n > will resolve shortly > (for now I'm leaving 64bit extract + sign extend + non constant m/n) > > some newlines for readability > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From hosking at cs.purdue.edu Sun Mar 7 17:03:51 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Mar 2010 11:03:51 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100307141218.728F62474001@birch.elegosoft.com> References: <20100307141218.728F62474001@birch.elegosoft.com> Message-ID: That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/07 15:12:18 > > Modified files: > cm3/m3-sys/m3front/src/builtinOps/: Number.m3 > > Log message: > Fix test p078. > Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it > easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at elego.de Sun Mar 7 17:08:50 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 7 Mar 2010 17:08:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100307160850.E8CB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/07 17:08:50 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Let's just preserve the historical sense of things for easier diffing from prehistory. [Jay, yes I know that you think it is easier to read without the logical negations, but I want to have something that avoids gratuitous changes in the record that make diffing with past versions noisier than necessary.] From jay.krell at cornell.edu Sun Mar 7 23:29:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Mar 2010 22:29:50 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100307141218.728F62474001@birch.elegosoft.com>, Message-ID: Imagine you were writing a bounds check with INTEGER. Would you write: a, min, max: INTEGER; IF a >= min AND a <= max reasonable IF min <= a AND a <= max reasonable IF NOT a < min AND NOT max < a seems kind of contorted? but ok. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Mar 2010 11:03:51 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 That's a cut-paste typo, not so much as any confusion in the comparison ops. I don't actually have much difficulty with the LT/LE comparisons versus the others you added. But... ok. On 7 Mar 2010, at 15:12, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/07 15:12:18 Modified files: cm3/m3-sys/m3front/src/builtinOps/: Number.m3 Log message: Fix test p078. Notice how the full assortment of LE/GE/LT/GT/EQ/NE makes it easier to read and write the code and get it correct! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 05:28:31 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:28:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308042831.4D0652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:28:31 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more 64bit division tests From jkrell at elego.de Mon Mar 8 05:47:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:47:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044736.39EF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:47:36 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 stdout.pgm stdout.pgm32 Log message: more division tests, in particular of constants that don't fit in 32bits and that are powers of 2 From jkrell at elego.de Mon Mar 8 05:48:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:48:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308044802.9DFD22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:48:02 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: inline 64bit sign extending extracts (constant m/n) actually related to sign extending 64bit right shift it depends on that for the implementation actually related to 64bit division with constants, since the frontend converts some of them to 64bit extract_mn (see test p227) From jay.krell at cornell.edu Mon Mar 8 05:48:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 04:48:49 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308044802.9DFD22474001@birch.elegosoft.com> References: <20100308044802.9DFD22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 05:48:02 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 05:48:02 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > inline 64bit sign extending extracts (constant m/n) > actually related to sign extending 64bit right shift > it depends on that for the implementation > actually related to 64bit division with constants, since > the frontend converts some of them to 64bit extract_mn (see test p227) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From jkrell at elego.de Mon Mar 8 05:57:13 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 5:57:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308045713.865762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 05:57:13 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c test_hand.c Log message: remove support for 64bit sign extending extract the backend inlines them all now (they always have constant m and n) From jkrell at elego.de Mon Mar 8 06:08:02 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 6:08:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308050802.414FB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 06:08:02 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: remove asserts from insert/extract, runtime checks are already done before this From jkrell at elego.de Mon Mar 8 10:41:15 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:41:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094115.6FFD32474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:41:15 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: fix last minute edits From jkrell at elego.de Mon Mar 8 10:45:03 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 10:45:03 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308094503.7B0842474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 10:45:03 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: perhaps cleaner to call the '1' functions less and the 'normal' functions more, only calling 'foo1' from 'foo' and nowhere else From jkrell at elego.de Mon Mar 8 13:26:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 13:26:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308122636.83CA12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 13:26:36 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" extract to not use tables and always be inlined for 64bit equivalent C code: UT __stdcall extract(UT x, uint32 offset, uint32 count) { x >>= offset; x &= ~((~(UT)0) << count); return x; } extract32 00000729: 8B4DEC MOV ECX tv.126[_m] 0000072C: 8B5DF4 MOV EBX tv.124[_a32] 0000072F: D3EB SHR EBX 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. 00000733: 8B4DE4 MOV ECX tv.128[_n] 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? 0000073B: D3E6 SHL ESI 0000073D: F7D6 NOT ESI 0000073F: 23DE AND EBX ESI extract64 000008E4: 8B4DD8 MOV ECX tv.134[_m] 000008E7: 8B5DE8 MOV EBX tv.131[_a64] 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 000008ED: 0FADD3 SHRD EBX EDX ECX 000008F0: D3EA SHR EDX 000008F2: F6C120 TEST ECX $32 000008F5: 7400 JE rel8 L.107 000008F7: 8BDA MOV EBX EDX 000008F9: 33D2 XOR EDX EDX set_label L.107 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. 000008FD: 8B4DD0 MOV ECX tv.136[_n] 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) 0000090A: 0FA5F8 SHLD EAX EDI ECX 0000090D: D3E7 SHL EDI 0000090F: F6C120 TEST ECX $32 00000912: 7400 JE rel8 L.108 00000914: 8BC7 MOV EAX EDI 00000916: 33FF XOR EDI EDI set_label L.108 00000918: F7D7 NOT EDI 0000091A: F7D0 NOT EAX 0000091C: 23DF AND EBX EDI 0000091E: 23D0 AND EDX EAX having n or m and n (or just m? I think so.) be constant leads to better code some other small cleanup, like avoiding calling find twice, I don't see why it was that way From jay.krell at cornell.edu Mon Mar 8 13:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 12:30:17 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308122636.83CA12474001@birch.elegosoft.com> References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:06:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:06:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308130650.47BA72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:06:50 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a lot of renaming for a lot more readability n => count m => offset consider that have functions insert, insert_n, insert_mn extract, extract_n, extract_mn it gets confusing and then more so, stack0 => stack_offset, stack_count, etc. stop0 => op_offset, op_count, etc. It's even worse there. Functions with so many parameters should use names, not stack offsets. From jay.krell at cornell.edu Mon Mar 8 14:07:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:07:54 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308130650.47BA72474001@birch.elegosoft.com> References: <20100308130650.47BA72474001@birch.elegosoft.com> Message-ID: diff attached it's a lot of churn but the result is much easier to read - Jay > Date: Mon, 8 Mar 2010 14:06:50 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:06:50 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a lot of renaming for a lot more readability > n => count > m => offset > > consider that have functions > insert, insert_n, insert_mn > extract, extract_n, extract_mn > > it gets confusing > > and then more so, > > stack0 => stack_offset, stack_count, etc. > stop0 => op_offset, op_count, etc. > > It's even worse there. Functions with > so many parameters should use names, not stack offsets. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:18:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:18:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308131806.6019F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:18:06 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little bit of cleanup and dead code removal including: another numbered to named variable sign_extending extract without constant offset/count From jay.krell at cornell.edu Mon Mar 8 14:18:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 13:18:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308131806.6019F2474001@birch.elegosoft.com> References: <20100308131806.6019F2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 14:18:06 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 14:18:06 > > Modified files: > cm3/m3-sys/m3back/src/: Stackx86.m3 > > Log message: > a little bit of cleanup and dead code removal > including: > another numbered to named variable > sign_extending extract without constant offset/count > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 14:53:34 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:53:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135335.0184A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:53:34 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: It helps to split TestInsert/TestExtract into TestInsert32/TestInsert64/TestExtract32/TestExtract64 because the backend reuses temporary variables and their names end up confusing, if you read the debug output. From jkrell at elego.de Mon Mar 8 14:54:10 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:54:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135410.663152474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:54:10 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: Main.m3 Log message: remove sign_extend, it was always 0 From jkrell at elego.de Mon Mar 8 14:59:26 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 14:59:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308135926.D46412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 14:59:26 Modified files: cm3/m3-sys/m3tests/src/p2/p227/: stdout.pgm stdout.pgm32 stdout.pgm64 Log message: update output: from LINUXLIBC6 and AMD64_DARWIN From hosking at cs.purdue.edu Mon Mar 8 16:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 8 Mar 2010 10:29:00 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com> Message-ID: You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/08 13:26:36 > > > > Modified files: > > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > > > Log message: > > "rewrite" extract to not use tables and always be inlined for 64bit > > > > equivalent C code: > > > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > > { > > x >>= offset; > > x &= ~((~(UT)0) << count); > > return x; > > } > > > > extract32 > > 00000729: 8B4DEC MOV ECX tv.126[_m] > > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > > 0000072F: D3EB SHR EBX > > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > > 00000733: 8B4DE4 MOV ECX tv.128[_n] > > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > > 0000073B: D3E6 SHL ESI > > 0000073D: F7D6 NOT ESI > > 0000073F: 23DE AND EBX ESI > > > > extract64 > > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > > 000008ED: 0FADD3 SHRD EBX EDX ECX > > 000008F0: D3EA SHR EDX > > 000008F2: F6C120 TEST ECX $32 > > 000008F5: 7400 JE rel8 L.107 > > 000008F7: 8BDA MOV EBX EDX > > 000008F9: 33D2 XOR EDX EDX > > set_label L.107 > > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > > 0000090A: 0FA5F8 SHLD EAX EDI ECX > > 0000090D: D3E7 SHL EDI > > 0000090F: F6C120 TEST ECX $32 > > 00000912: 7400 JE rel8 L.108 > > 00000914: 8BC7 MOV EAX EDI > > 00000916: 33FF XOR EDI EDI > > set_label L.108 > > 00000918: F7D7 NOT EDI > > 0000091A: F7D0 NOT EAX > > 0000091C: 23DF AND EBX EDI > > 0000091E: 23D0 AND EDX EAX > > > > having n or m and n (or just m? I think so.) be constant leads to better code > > > > some other small cleanup, like avoiding calling find twice, > > I don't see why it was that way > > > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 8 17:03:48 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:03:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308160348.F40EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:03:48 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 Log message: "rewrite" insert to not use tables and to inline 64bit operations It is modeled after: T insert(T to, T from, uint32 offset, uint32 count) { T mask = ((~((~(T)0) << count)) << offset); return (to & ~mask) | ((from << offset) & mask); } I spent some time trying to remove the unnecessary instructions. No luck yet. The problem is the codegen wants to preserve offset/count after we are done with them. The usage of the constant "-1" will be optimized later. Constant offset and count should generate much better code. Just constant offset or count, not much different (shift immediate instead of shift by ecx). er, actually the shifts might be significantly optimized. Calculation of the mask ought to be better just for constant count, to be looked at later. It may be profitable to come up with other formulas. These at least are "branch free" (except for the branches within the shifts). The basic general patterns are, which you can see follow the C code closely: insert Word.32 00000226: 8B4DD0 MOV ECX tv.103[_n] 00000229: BEFFFFFFFF MOV ESI $4294967295 0000022E: D3E6 SHL ESI 00000230: F7D6 NOT ESI 00000232: 8BF9 MOV EDI ECX This isn't needed! 00000234: 8B4DD8 MOV ECX tv.101[_m] 00000237: D3E6 SHL ESI 00000239: D3E2 SHL EDX 0000023B: 23D6 AND EDX ESI 0000023D: F7D6 NOT ESI 0000023F: 23DE AND EBX ESI 00000241: 0BDA OR EBX EDX insert Word.64 000004EB: 8B4DB0 MOV ECX tv.117[_n] 000004EE: BBFFFFFFFF MOV EBX $4294967295 000004F3: BEFFFFFFFF MOV ESI $4294967295 000004F8: 0FA5DE SHLD ESI EBX ECX 000004FB: D3E3 SHL EBX 000004FD: F6C120 TEST ECX $32 00000500: 7400 JE rel8 L.75 00000502: 8BF3 MOV ESI EBX 00000504: 33DB XOR EBX EBX set_label L.75 00000506: F7D3 NOT EBX 00000508: F7D6 NOT ESI 0000050A: 8BF9 MOV EDI ECX 0000050C: 8B4DB8 MOV ECX tv.115[_m] 0000050F: 0FA5DE SHLD ESI EBX ECX 00000512: D3E3 SHL EBX 00000514: F6C120 TEST ECX $32 00000517: 7400 JE rel8 L.76 00000519: 8BF3 MOV ESI EBX 0000051B: 33DB XOR EBX EBX set_label L.76 0000051D: 0FA5C2 SHLD EDX EAX ECX 00000520: D3E0 SHL EAX 00000522: F6C120 TEST ECX $32 00000525: 7400 JE rel8 L.77 00000527: 8BD0 MOV EDX EAX 00000529: 33C0 XOR EAX EAX set_label L.77 0000052B: 23C3 AND EAX EBX 0000052D: 23D6 AND EDX ESI 0000052F: F7D3 NOT EBX 00000531: F7D6 NOT ESI declare_temp 4 4 Int.32 F tv.119[T$119] -88 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! 00000536: 8B7DE8 MOV EDI tv.108[_a64] declare_temp 4 4 Int.32 F tv.120[T$120] -92 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 0000053F: 23FB AND EDI EBX 00000541: 23CE AND ECX ESI 00000543: 0BF8 OR EDI EAX 00000545: 0BCA OR ECX EDX free_temp tv.120[T$120] free_temp tv.119[T$119] From jay.krell at cornell.edu Mon Mar 8 17:04:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:04:45 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , Message-ID: Fair enough. - Jay From: hosking at cs.purdue.edu Date: Mon, 8 Mar 2010 10:29:00 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. On 8 Mar 2010, at 07:30, Jay K wrote: diff attached If folks really want to use tables or function calls here, let me know. The data was historically problematic, though we worked out the problems. - It was initialized at runtime which has a race condition, fixed years ago. - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. The data is still used by Word.Insert and Long.Insert is still a function, but those are my next targets. This is a case where the user does write a function call. Word.Extract or Long.Extract. (So the function should have been called Long__Extract.) - Jay > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x >>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > <1.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 8 17:18:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Mar 2010 16:18:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100308160348.F40EB2474001@birch.elegosoft.com> References: <20100308160348.F40EB2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Mon, 8 Mar 2010 17:03:48 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 17:03:48 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" insert to not use tables and to inline 64bit operations > > It is modeled after: > > T insert(T to, T from, uint32 offset, uint32 count) > { > T mask = ((~((~(T)0) << count)) << offset); > return (to & ~mask) | ((from << offset) & mask); > } > > I spent some time trying to remove the unnecessary instructions. > No luck yet. The problem is the codegen wants to preserve offset/count > after we are done with them. > > The usage of the constant "-1" will be optimized later. > > Constant offset and count should generate much better code. > Just constant offset or count, not much different (shift immediate instead of shift by ecx). > er, actually the shifts might be significantly optimized. > Calculation of the mask ought to be better just for constant count, to be looked at later. > > It may be profitable to come up with other formulas. > These at least are "branch free" (except for the branches within the shifts). > > The basic general patterns are, which you can see follow the C code closely: > > insert Word.32 > 00000226: 8B4DD0 MOV ECX tv.103[_n] > 00000229: BEFFFFFFFF MOV ESI $4294967295 > 0000022E: D3E6 SHL ESI > 00000230: F7D6 NOT ESI > 00000232: 8BF9 MOV EDI ECX This isn't needed! > 00000234: 8B4DD8 MOV ECX tv.101[_m] > 00000237: D3E6 SHL ESI > 00000239: D3E2 SHL EDX > 0000023B: 23D6 AND EDX ESI > 0000023D: F7D6 NOT ESI > 0000023F: 23DE AND EBX ESI > 00000241: 0BDA OR EBX EDX > > insert Word.64 > 000004EB: 8B4DB0 MOV ECX tv.117[_n] > 000004EE: BBFFFFFFFF MOV EBX $4294967295 > 000004F3: BEFFFFFFFF MOV ESI $4294967295 > 000004F8: 0FA5DE SHLD ESI EBX ECX > 000004FB: D3E3 SHL EBX > 000004FD: F6C120 TEST ECX $32 > 00000500: 7400 JE rel8 L.75 > 00000502: 8BF3 MOV ESI EBX > 00000504: 33DB XOR EBX EBX > set_label L.75 > 00000506: F7D3 NOT EBX > 00000508: F7D6 NOT ESI > 0000050A: 8BF9 MOV EDI ECX > 0000050C: 8B4DB8 MOV ECX tv.115[_m] > 0000050F: 0FA5DE SHLD ESI EBX ECX > 00000512: D3E3 SHL EBX > 00000514: F6C120 TEST ECX $32 > 00000517: 7400 JE rel8 L.76 > 00000519: 8BF3 MOV ESI EBX > 0000051B: 33DB XOR EBX EBX > set_label L.76 > 0000051D: 0FA5C2 SHLD EDX EAX ECX > 00000520: D3E0 SHL EAX > 00000522: F6C120 TEST ECX $32 > 00000525: 7400 JE rel8 L.77 > 00000527: 8BD0 MOV EDX EAX > 00000529: 33C0 XOR EAX EAX > set_label L.77 > 0000052B: 23C3 AND EAX EBX > 0000052D: 23D6 AND EDX ESI > 0000052F: F7D3 NOT EBX > 00000531: F7D6 NOT ESI > declare_temp 4 4 Int.32 F tv.119[T$119] -88 > 00000533: 897DA8 MOV tv.119[T$119] EDI This isn't needed! > 00000536: 8B7DE8 MOV EDI tv.108[_a64] > declare_temp 4 4 Int.32 F tv.120[T$120] -92 > 00000539: 894DA4 MOV tv.120[T$120] ECX This isn't needed! > 0000053C: 8B4DEC MOV ECX tv.108[_a64]+4 > 0000053F: 23FB AND EDI EBX > 00000541: 23CE AND ECX ESI > 00000543: 0BF8 OR EDI EAX > 00000545: 0BCA OR ECX EDX > free_temp tv.120[T$120] > free_temp tv.119[T$119] > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 8 17:21:49 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 8 Mar 2010 17:21:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100308162149.D4E4A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/08 17:21:49 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Removed files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: remove no longer used 64bit insert/extract functions remove no longer used _lowbits/_highbits tables that NT386 used to use for 32bit insert/extract test code has nothing left to test now (there is still stuff in hand.c, but test_hand.c didn't test it) From jkrell at elego.de Tue Mar 9 17:09:00 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:09:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309160900.CF5352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:09:00 Modified files: cm3/scripts/python/: pylib.py Log message: fix newlines From jkrell at elego.de Tue Mar 9 17:10:08 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:10:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309161008.3D8192474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:10:08 Modified files: cm3/scripts/python/: pylib.py Log message: code to detect Visual C++ version from its banner, so we can build an .msi for every or almost every one (I'm missing some right now), preprocessing the string _MSC_VER is another good way From jkrell at elego.de Tue Mar 9 17:29:37 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:29:37 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309162937.904482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:29:37 Modified files: cm3/scripts/python/: pylib.py Log message: don't put cm3cg in NT386 packages From jkrell at elego.de Tue Mar 9 17:41:05 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:41:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309164105.1EB322474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:41:05 Modified files: cm3/scripts/python/: pylib.py Log message: tag NT386 distribution file names with Visual C++ version e.g. cm3-std-NT386-d5.8.2-VC90.tgz, m3-std-NT386-d5.8.2-VC80.msi, etc. From jkrell at elego.de Tue Mar 9 17:56:19 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 9 Mar 2010 17:56:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100309165619.700AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/09 17:56:19 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: COPY from head: PPC64_DARWIN support remove PIC building some SPARC bootstraps don't put cm3cg in NT386 packages stamp NT386 package files with Visual C++ version remove leading underscore from ConvertFromCygwinPath, ConvertToCygwinPath so they are public remove 'base' and 'core' package sets some Interix stuff (which I think isn't needed anywhere) support for editing in -debug switch From jkrell at elego.de Wed Mar 10 09:43:20 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 9:43:20 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310084320.99E8B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 09:43:20 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86Rep.i3 Stackx86.i3 Stackx86.m3 Log message: selective 'INTEGER' => 'CARDINAL' From jkrell at elego.de Wed Mar 10 11:31:36 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:31:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103136.BDE3F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) From jkrell at elego.de Wed Mar 10 11:32:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:32:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103247.98D402474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:32:47 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: remove whitespace from ends of lines From jkrell at elego.de Wed Mar 10 11:34:05 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:05 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103405.A42882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:05 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: when checking for case insensitive inequality, first check for case sensitive equality From jkrell at elego.de Wed Mar 10 11:34:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:34:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103456.7D46B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:34:56 Modified files: cm3/m3-libs/sysutils/src/: PathReprCommon.m3 Log message: fix typos in comments From jkrell at elego.de Wed Mar 10 11:37:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:37:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310103756.9D3BB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:37:56 Modified files: cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: if asked to replace something with itself, just return the original without any searching From jkrell at elego.de Wed Mar 10 11:41:39 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:41:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104139.B6A712474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:41:39 Modified files: cm3/m3-libs/sysutils/src/: EnvUtils.m3 FSUtils.i3 FSUtils.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 MsgX.m3 OSSpecials.i3 PathRepr.i3 ProcessEnv.i3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 m3makefile cm3/m3-libs/sysutils/src/POSIX/: OSSpecialsPosix.m3 PathReprPosix.m3 SystemPosix.m3 m3makefile cm3/m3-libs/sysutils/src/WIN32/: OSSpecialsWin32.m3 PathReprWin32.m3 SystemWin32.m3 m3makefile cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 m3makefile cm3/m3-libs/sysutils/src/pm3/: TextUtils.m3 m3makefile Log message: remove $Id$, it adds noise when comparing branches I'll take the liberty of assuming $Id$ is not part of the license text that is usually adjacent to. From jkrell at elego.de Wed Mar 10 11:45:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 11:45:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310104544.7AF4F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:45:44 Modified files: cm3/m3-libs/sysutils/src/: Confirmation.i3 Confirmation.m3 ConnectRdWr.m3 EnvUtils.i3 EnvUtils.m3 FSUtils.m3 FSUtilsUnsafe.i3 FastLex.i3 FingerprintFmt.i3 FingerprintFmt.m3 MsgIF.i3 MsgIF.m3 MsgX.i3 OSSpecials.i3 PathReprCommon.m3 ProcessEnv.m3 SMsg.i3 SMsg.m3 System.i3 System.m3 TextReadingUtils.i3 TextReadingUtils.m3 TextUtils.i3 cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 cm3/m3-libs/sysutils/src/pm3/: RdExtras.m3 TextUtils.m3 Log message: remove whitespace at ends of lines From jkrell at elego.de Wed Mar 10 15:18:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:18:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310141843.A73942474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:18:43 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: compare operandPart when comparing stackp really something larger is bothering me, looking into the assertion failure when I try to remove unnecessary instructions from insert/extract We get into a situation where part of a value is in one of the correct registers, but hi is in low or vice versa, and in moving things around, we do the wrong thing. Like if we want return value in EDX:EAX and the value is currently in EAX:ECX, we do like: XCHG EAX,ECX ; put the low part in EAX where it belongs MOV EDX, EAX ; wrong, should be MOV EDX, ECX, or reverse ; the two instructions I don't know that there is a problem here in practise or not, since I've only seen it so far looking at uncommited changes. From jkrell at elego.de Wed Mar 10 15:22:56 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:22:56 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142256.0812A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:22:56 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: store operandPart := -1 whenever we store stackp := -1 From jkrell at elego.de Wed Mar 10 15:24:00 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:24:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310142400.40C1A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:24:00 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: finish the change that follows errors with assertion failures From jkrell at elego.de Wed Mar 10 15:40:47 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:40:47 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144047.BD9A02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:40:47 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: just add comments From jkrell at elego.de Wed Mar 10 15:41:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:41:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310144132.E0E692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:41:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: slight simplification, perhaps, in procedure swap From jkrell at elego.de Wed Mar 10 15:51:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:51:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145132.9770E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:51:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: safe keeping: this generates insert/extract better but either causes or reveals a register allocation problem, followed by an assertion failure; the register allocation problem can be seen here: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG EAX ECX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] 64bit return values are EDX:EAX. This has, by chance, the value in EAX:ECX, and then messes up converting it to EDX:EAX. From jkrell at elego.de Wed Mar 10 15:52:51 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 15:52:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310145251.900B92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 15:52:51 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: go back to version 1.131 From jkrell at elego.de Wed Mar 10 16:12:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:12:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310151231.8F9412474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:12:31 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Now that I finally think enough, a nice little fix to the register allocator to handle when a multi register operand is partly in the right registers, but with the part mixed up. It yields us at the end of Long__Insert this: 000003C6: 8B4D08 MOV ECX tv.65[_x] 000003C9: 8B450C MOV EAX tv.65[_x]+4 000003CC: 23CB AND ECX EBX 000003CE: 23C2 AND EAX EDX 000003D0: 0BCE OR ECX ESI 000003D2: 0BC7 OR EAX EDI exit_proc Int.64 000003D4: 91 XCHG ECX EAX 000003D5: 8BD0 MOV EDX EAX 000003D7: E900000000 JMP L.39 end_procedure p.24[_Long__Insert] again it'd be nice if we had ECX:EAX in the first place instead of EAX:ECX, or even EDX:EAX. And then, a roundabout but understandable way to eliminate the unnecessary stores in insert/extract. The extra checking under -debug forces to rearrange the virtual stack and discard(), rather than just say dealloc_reg. If "location" could be "nowhere" that might help, but we have to chose between immediate, register, float stack, memory_variable. And then Modula-3 WITH either because of how it behaves or because of my confusion -- I think actually for reasons related to "safety", we have to "reevaluate" a few times -- each time we discard anything from the stack. Leading to a bit extra code but it is fairly clear. From jkrell at elego.de Wed Mar 10 16:49:26 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 16:49:26 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310154926.63AFE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 16:49:26 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: two small improvements 1) If we were trying to put 64bit value in EDX:EAX such as we assume is for a return value, and either part of the value wasn't in place, we would do work for both parts. The result was typically throwing in "xchg edx,edx" which does nothing. Now we only work on whatever part isn't where it should be. This could be seen e.g. in Long__Plus. Caught by adding assert to # from in swapreg. 2) If we are allocating a 64bit value and EAX is chosen for one of the registers, force it to be the low part. This saves an instruction in Long__Insert and easy to imagine elsewhere. There's really no downside. Unless maybe you are about to shift or rotate by a constant of 32 or more, or extract/insert with an offset of 32 or more (and even then, I think we can address that) If the high part is already in a register (i.e. EAX), then leave it there. I don't think this can happen since, like, we don't have a notion of "splitting" or "merging" allocation. e.g., ideally: stuff like: a := 0L or a := -1L would fit in one register or a := 0L; a := Long.Or(a, VAL(integer, LONGINT)) would be an immediate plus one register, instead of two registers From hosking at cs.purdue.edu Wed Mar 10 16:53:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 10:53:16 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100310103136.BDE3F2474001@birch.elegosoft.com> References: <20100310103136.BDE3F2474001@birch.elegosoft.com> Message-ID: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Mar 10 17:00:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 16:00:27 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). - Jay From: hosking at cs.purdue.edu Date: Wed, 10 Mar 2010 10:53:16 -0500 To: jkrell at elego.de CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I thought we decided these hacks were not necessary moving forward. If you want to build CM3 you need an up to date compiler... etc. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 11:31, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 11:31:36 Modified files: cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 Log message: copy in: RdExtras.Skip RdExtras.GetText RdExtras.GetUntil TextExtras.FindSub TextExtras.CIEqual TextExtras.FindSub TextExtras.FindChar TextExtras.FindCharSet for portability to older releases (5.1.3a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Mar 10 17:08:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 11:08:01 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100310103136.BDE3F2474001@birch.elegosoft.com>, <7BA90848-48E1-4086-9D3D-26400DE14E31@cs.purdue.edu> Message-ID: <49CA2A26-57BD-462F-97A6-A86B21107D50@cs.purdue.edu> OK. On 10 Mar 2010, at 11:00, Jay K wrote: > I'm not sure I agree, and other than sorting out my own use forward slashes in config files and Python, I believe you can bootstrap from 5.1.3a. If this is "all" it takes (plus the various other fairly small hacks), I think it is probably worthwhile. > I did build a bunch of the current system with 5.1.3a just now but then I messed up. I had accidentally deleted a bunch of backups (or copied a broken compiler over them). > > > - Jay > > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 10:53:16 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I thought we decided these hacks were not necessary moving forward. > If you want to build CM3 you need an up to date compiler... etc. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 10 Mar 2010, at 11:31, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/10 11:31:36 > > Modified files: > cm3/m3-libs/sysutils/src/: System.m3 TextReadingUtils.m3 > cm3/m3-libs/sysutils/src/cm3/: TextUtils.m3 > > Log message: > copy in: > RdExtras.Skip > RdExtras.GetText > RdExtras.GetUntil > TextExtras.FindSub > TextExtras.CIEqual > TextExtras.FindSub > TextExtras.FindChar > TextExtras.FindCharSet > > for portability to older releases (5.1.3a) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Wed Mar 10 18:04:04 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170405.2E11D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:04 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 Log message: replace e.g.: 00000022: B8 FF FF FF FF mov eax,0FFFFFFFFh 00000027: BA FF FF FF FF mov edx,0FFFFFFFFh with: 00000020: 83 C8 FF or eax,0FFFFFFFFh 00000023: 83 CA FF or edx,0FFFFFFFFh (mov reg, -1 with or reg, -1 -- smaller encoding, same meaning; both 32bit and 64bit operands) notice the code is a bit wierd, source type vs. dest type, and the number 4 is too creeping (this code should target AMD64_NT eventually) From jkrell at elego.de Wed Mar 10 18:04:31 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 18:04:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310170431.684F72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 18:04:31 Modified files: cm3/m3-sys/m3back/src/: TWordN.i3 Log message: fix whitespace From jkrell at elego.de Wed Mar 10 21:52:30 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205230.445EB2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:30 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Handle when both registers are allocated to an operand, but in the wrong parts. e.g. we have EAX:EDX but want EDX:EAX. Not actually tested, nor an example seen, but I was thinking about it and it seems clear the previous code would do two swaps, leaving things incorrect. From jkrell at elego.de Wed Mar 10 21:52:54 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:52:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205254.4080C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:52:54 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: fix comment From jkrell at elego.de Wed Mar 10 21:56:25 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:56:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205625.B33062474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:56:25 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repition From jkrell at elego.de Wed Mar 10 21:57:33 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:57:33 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205733.45C8E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:57:33 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: a little less repitition, should be equivalent From jkrell at elego.de Wed Mar 10 21:58:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 10 Mar 2010 21:58:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100310205844.40A142474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/10 21:58:44 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: should be equivalent From jay.krell at cornell.edu Wed Mar 10 23:27:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 10 Mar 2010 22:27:55 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? You know, that'd be a great hint to: - definitely definitely definitely definitely inline - if we know this thing existed, we could use it instead of a .c file. - along with the function's name for the invocations that aren't the function? Why provide the function anyway? In case someone takes the address? - Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> > <1.txt> > From hosking at cs.purdue.edu Thu Mar 11 01:57:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 19:57:17 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , Message-ID: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Yes, someone can pass the function as a parameter. I don't understand the rest of what you are saying. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 10 Mar 2010, at 17:27, Jay K wrote: > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >> <1.txt> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Mar 11 02:30:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 01:30:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. Granted at least two things: Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. And I'm inlined to just always inline anyway. (I still don't like the term "Long" here. It doesn't convey unsigned.) - Jay ________________________________ > Subject: Re: [M3commit] CVS Update: cm3 > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 19:57:17 -0500 > CC: m3commit at elegosoft.com > To: jay.krell at cornell.edu > > > > Yes, someone can pass the function as a parameter. > > I don't understand the rest of what you are saying. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 10 Mar 2010, at 17:27, Jay K wrote: > > > Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? > You know, that'd be a great hint to: > > - definitely definitely definitely definitely inline > - if we know this thing existed, we could use it instead of a .c file. > - along with the function's name for the invocations that aren't the function? > > > Why provide the function anyway? In case someone takes the address? > > > > - Jay > > > ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 16:04:45 +0000 > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Fair enough. > > > > - Jay > > > > ________________________________ > > From: hosking at cs.purdue.edu > Date: Mon, 8 Mar 2010 10:29:00 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > > You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. > > > > On 8 Mar 2010, at 07:30, Jay K wrote: > > > > diff attached > > > If folks really want to use tables or function calls here, let me know. > > > The data was historically problematic, though we worked out the problems. > - It was initialized at runtime which has a race condition, fixed years ago. > - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. > > The data is still used by Word.Insert and Long.Insert is still a function, but those > are my next targets. > > > This is a case where the user does write a function call. Word.Extract or Long.Extract. > (So the function should have been called Long__Extract.) > > > - Jay > > Date: Mon, 8 Mar 2010 13:26:36 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/08 13:26:36 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 > > Log message: > "rewrite" extract to not use tables and always be inlined for 64bit > > equivalent C code: > > UT __stdcall extract(UT x, uint32 offset, uint32 count) > { > x>>= offset; > x &= ~((~(UT)0) << count); > return x; > } > > extract32 > 00000729: 8B4DEC MOV ECX tv.126[_m] > 0000072C: 8B5DF4 MOV EBX tv.124[_a32] > 0000072F: D3EB SHR EBX > 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. > 00000733: 8B4DE4 MOV ECX tv.128[_n] > 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? > 0000073B: D3E6 SHL ESI > 0000073D: F7D6 NOT ESI > 0000073F: 23DE AND EBX ESI > > extract64 > 000008E4: 8B4DD8 MOV ECX tv.134[_m] > 000008E7: 8B5DE8 MOV EBX tv.131[_a64] > 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 > 000008ED: 0FADD3 SHRD EBX EDX ECX > 000008F0: D3EA SHR EDX > 000008F2: F6C120 TEST ECX $32 > 000008F5: 7400 JE rel8 L.107 > 000008F7: 8BDA MOV EBX EDX > 000008F9: 33D2 XOR EDX EDX > set_label L.107 > 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. > 000008FD: 8B4DD0 MOV ECX tv.136[_n] > 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? > 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) > 0000090A: 0FA5F8 SHLD EAX EDI ECX > 0000090D: D3E7 SHL EDI > 0000090F: F6C120 TEST ECX $32 > 00000912: 7400 JE rel8 L.108 > 00000914: 8BC7 MOV EAX EDI > 00000916: 33FF XOR EDI EDI > set_label L.108 > 00000918: F7D7 NOT EDI > 0000091A: F7D0 NOT EAX > 0000091C: 23DF AND EBX EDI > 0000091E: 23D0 AND EDX EAX > > having n or m and n (or just m? I think so.) be constant leads to better code > > some other small cleanup, like avoiding calling find twice, > I don't see why it was that way > > <1.txt> > > From hosking at cs.purdue.edu Thu Mar 11 03:01:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 10 Mar 2010 21:01:54 -0500 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100308122636.83CA12474001@birch.elegosoft.com>, , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu> Message-ID: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? On 10 Mar 2010, at 20:30, Jay K wrote: > > If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. > > > That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. > > > That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. > > Granted at least two things: > Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. > And I'm inlined to just always inline anyway. > > > (I still don't like the term "Long" here. It doesn't convey unsigned.) > > > - Jay > > > > ________________________________ >> Subject: Re: [M3commit] CVS Update: cm3 >> From: hosking at cs.purdue.edu >> Date: Wed, 10 Mar 2010 19:57:17 -0500 >> CC: m3commit at elegosoft.com >> To: jay.krell at cornell.edu >> >> >> >> Yes, someone can pass the function as a parameter. >> >> I don't understand the rest of what you are saying. >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 10 Mar 2010, at 17:27, Jay K wrote: >> >> >> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >> You know, that'd be a great hint to: >> >> - definitely definitely definitely definitely inline >> - if we know this thing existed, we could use it instead of a .c file. >> - along with the function's name for the invocations that aren't the function? >> >> >> Why provide the function anyway? In case someone takes the address? >> >> >> >> - Jay >> >> >> ________________________________ >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 16:04:45 +0000 >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> >> >> >> >> Fair enough. >> >> >> >> - Jay >> >> >> >> ________________________________ >> >> From: hosking at cs.purdue.edu >> Date: Mon, 8 Mar 2010 10:29:00 -0500 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> >> >> >> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >> >> >> >> On 8 Mar 2010, at 07:30, Jay K wrote: >> >> >> >> diff attached >> >> >> If folks really want to use tables or function calls here, let me know. >> >> >> The data was historically problematic, though we worked out the problems. >> - It was initialized at runtime which has a race condition, fixed years ago. >> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >> >> The data is still used by Word.Insert and Long.Insert is still a function, but those >> are my next targets. >> >> >> This is a case where the user does write a function call. Word.Extract or Long.Extract. >> (So the function should have been called Long__Extract.) >> >> >> - Jay >> >> Date: Mon, 8 Mar 2010 13:26:36 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/03/08 13:26:36 >> >> Modified files: >> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >> >> Log message: >> "rewrite" extract to not use tables and always be inlined for 64bit >> >> equivalent C code: >> >> UT __stdcall extract(UT x, uint32 offset, uint32 count) >> { >> x>>= offset; >> x &= ~((~(UT)0) << count); >> return x; >> } >> >> extract32 >> 00000729: 8B4DEC MOV ECX tv.126[_m] >> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >> 0000072F: D3EB SHR EBX >> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >> 00000733: 8B4DE4 MOV ECX tv.128[_n] >> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >> 0000073B: D3E6 SHL ESI >> 0000073D: F7D6 NOT ESI >> 0000073F: 23DE AND EBX ESI >> >> extract64 >> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >> 000008ED: 0FADD3 SHRD EBX EDX ECX >> 000008F0: D3EA SHR EDX >> 000008F2: F6C120 TEST ECX $32 >> 000008F5: 7400 JE rel8 L.107 >> 000008F7: 8BDA MOV EBX EDX >> 000008F9: 33D2 XOR EDX EDX >> set_label L.107 >> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >> 0000090A: 0FA5F8 SHLD EAX EDI ECX >> 0000090D: D3E7 SHL EDI >> 0000090F: F6C120 TEST ECX $32 >> 00000912: 7400 JE rel8 L.108 >> 00000914: 8BC7 MOV EAX EDI >> 00000916: 33FF XOR EDI EDI >> set_label L.108 >> 00000918: F7D7 NOT EDI >> 0000091A: F7D0 NOT EAX >> 0000091C: 23DF AND EBX EDI >> 0000091E: 23D0 AND EDX EAX >> >> having n or m and n (or just m? I think so.) be constant leads to better code >> >> some other small cleanup, like avoiding calling find twice, >> I don't see why it was that way >> >> <1.txt> >> >> From jay.krell at cornell.edu Thu Mar 11 05:10:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Mar 2010 04:10:40 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> References: <20100308122636.83CA12474001@birch.elegosoft.com>, ,,, , , , , , , , <5ECDB225-60F1-4094-96EA-B7BB0EBE340A@cs.purdue.edu>, , <60FB82E7-B3B3-45ED-973B-191F7992A4E2@cs.purdue.edu> Message-ID: Long.LeftShift is not a great example. Sorry. Long.Shift, Long.Rotate, Long.Times, LongDivide. Those are or "could be" large. Currently the later three all call functions and are therefore short. Integer.Multiple, Divide, Remainder, similarly uncertain. They call functions, the functions aren't short. I was also thinking, some of these functions, esp. 64bit shift/rotate could be shorter as loops. But I think not worthwhile. To be clear, even though "parse.c" "never" generates function calls (except for set operations), the gcc backend itself often does. The functions are in libgcc. You know..I find it hard to decide about compiler generated function calls. Definitely for size optimization they can be a win. But I just somehow vaguely don't like them. In many cases, the decision is not difficult. set_singleton and set_member are good examples. They could be inlined and be very small. But Shift, Rotate, Multiply, Divide, it gets less clear. But no matter how large an inline form, I think when interface word/long maps directly to these operations, they should be inlined. And then if there are places that don't inline, they should call the "instantiations" in interface word/long. And then, furthermore, we should consider an interface for "Integer.Divide/Multiple/Remainder"? A place to park the possibly large code? - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 10 Mar 2010 21:01:54 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I am confused. The intention is that Long.LeftShift is always inlined wherever it is called. Is the code for it really that hairy? > > On 10 Mar 2010, at 20:30, Jay K wrote: > >> >> If there exists an inline expansion, and it is large, but there is a function whose job it is to hold the expansion, whether it is inline or not, and the backend was informed of this function's name, and whether or not it was currently producing it, the backend could generate the inline expansion for Long__LeftShift, but otherwise generate calls to it. >> >> >> That is, e.g. m3cg.left_shift(type := int64|word64) could chose to either call Long__LeftShift or generate the body of Long__LeftShift. Not based on some "is inlining profitable heuristic", but specifically if told it is generating the function Long__LeftShift or not. >> >> >> That is, there's no point in having a C function m3_left_shift64 or somesuch, and having Long__LeftShift call it. Instead a backend should generate the body of Long__LeftShift inline when told it is generating that function, vs. generating a call to that function when it is otherwise asked to do a 64bit leftshift if it decides that inlining it every time is too large. >> >> Granted at least two things: >> Given 64bit target, Long__LeftShift vs. Word__LeftShift is ambiguous. >> And I'm inlined to just always inline anyway. >> >> >> (I still don't like the term "Long" here. It doesn't convey unsigned.) >> >> >> - Jay >> >> >> >> ________________________________ >>> Subject: Re: [M3commit] CVS Update: cm3 >>> From: hosking at cs.purdue.edu >>> Date: Wed, 10 Mar 2010 19:57:17 -0500 >>> CC: m3commit at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> >>> >>> Yes, someone can pass the function as a parameter. >>> >>> I don't understand the rest of what you are saying. >>> >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 10 Mar 2010, at 17:27, Jay K wrote: >>> >>> >>> Hey, should we maybe have a flag that indicates we are producing a function that is meant to provide and only provide exactly the functionality of the "one" m3cg call? >>> You know, that'd be a great hint to: >>> >>> - definitely definitely definitely definitely inline >>> - if we know this thing existed, we could use it instead of a .c file. >>> - along with the function's name for the invocations that aren't the function? >>> >>> >>> Why provide the function anyway? In case someone takes the address? >>> >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 16:04:45 +0000 >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> >>> >>> >>> >>> Fair enough. >>> >>> >>> >>> - Jay >>> >>> >>> >>> ________________________________ >>> >>> From: hosking at cs.purdue.edu >>> Date: Mon, 8 Mar 2010 10:29:00 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> >>> >>> >>> You can't call the support function Long__Extract because we already have a Long__Extract in m3core/src/word. It is the library representative of the front-end compiler-generated (inlined) Long.Extract. >>> >>> >>> >>> On 8 Mar 2010, at 07:30, Jay K wrote: >>> >>> >>> >>> diff attached >>> >>> >>> If folks really want to use tables or function calls here, let me know. >>> >>> >>> The data was historically problematic, though we worked out the problems. >>> - It was initialized at runtime which has a race condition, fixed years ago. >>> - It can't be "exported" on NT386 (which is the only platform that uses it) and must be statically linked. >>> >>> The data is still used by Word.Insert and Long.Insert is still a function, but those >>> are my next targets. >>> >>> >>> This is a case where the user does write a function call. Word.Extract or Long.Extract. >>> (So the function should have been called Long__Extract.) >>> >>> >>> - Jay >>> >>> Date: Mon, 8 Mar 2010 13:26:36 +0000 >>> To: m3commit at elegosoft.com >>> From: jkrell at elego.de >>> Subject: [M3commit] CVS Update: cm3 >>> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/03/08 13:26:36 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: M3x86.m3 Stackx86.i3 Stackx86.m3 >>> >>> Log message: >>> "rewrite" extract to not use tables and always be inlined for 64bit >>> >>> equivalent C code: >>> >>> UT __stdcall extract(UT x, uint32 offset, uint32 count) >>> { >>> x>>= offset; >>> x &= ~((~(UT)0) << count); >>> return x; >>> } >>> >>> extract32 >>> 00000729: 8B4DEC MOV ECX tv.126[_m] >>> 0000072C: 8B5DF4 MOV EBX tv.124[_a32] >>> 0000072F: D3EB SHR EBX >>> 00000731: 8BD1 MOV EDX ECX This is pointless and I'll try to remove. >>> 00000733: 8B4DE4 MOV ECX tv.128[_n] >>> 00000736: BEFFFFFFFF MOV ESI $4294967295 I'll look for smaller form of this. or esi -1? >>> 0000073B: D3E6 SHL ESI >>> 0000073D: F7D6 NOT ESI >>> 0000073F: 23DE AND EBX ESI >>> >>> extract64 >>> 000008E4: 8B4DD8 MOV ECX tv.134[_m] >>> 000008E7: 8B5DE8 MOV EBX tv.131[_a64] >>> 000008EA: 8B55EC MOV EDX tv.131[_a64]+4 >>> 000008ED: 0FADD3 SHRD EBX EDX ECX >>> 000008F0: D3EA SHR EDX >>> 000008F2: F6C120 TEST ECX $32 >>> 000008F5: 7400 JE rel8 L.107 >>> 000008F7: 8BDA MOV EBX EDX >>> 000008F9: 33D2 XOR EDX EDX >>> set_label L.107 >>> 000008FB: 8BF1 MOV ESI ECX This is pointless and I'll try to remove. >>> 000008FD: 8B4DD0 MOV ECX tv.136[_n] >>> 00000900: BFFFFFFFFF MOV EDI $4294967295 I'll look for smaller form of this. or edi -1? >>> 00000905: B8FFFFFFFF MOV EAX $4294967295 I'll look for smaller form of this. (heck, at least mov edi, eax) >>> 0000090A: 0FA5F8 SHLD EAX EDI ECX >>> 0000090D: D3E7 SHL EDI >>> 0000090F: F6C120 TEST ECX $32 >>> 00000912: 7400 JE rel8 L.108 >>> 00000914: 8BC7 MOV EAX EDI >>> 00000916: 33FF XOR EDI EDI >>> set_label L.108 >>> 00000918: F7D7 NOT EDI >>> 0000091A: F7D0 NOT EAX >>> 0000091C: 23DF AND EBX EDI >>> 0000091E: 23D0 AND EDX EAX >>> >>> having n or m and n (or just m? I think so.) be constant leads to better code >>> >>> some other small cleanup, like avoiding calling find twice, >>> I don't see why it was that way >>> >>> <1.txt> >>> >>> > From hosking at elego.de Thu Mar 11 06:24:29 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:24:29 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311052429.3EFD72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:24:29 Modified files: cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c Log message: Use BIT_FIELD_REF for extract_mn. From hosking at elego.de Thu Mar 11 06:36:35 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:36:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311053636.074602474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:36:35 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: A little easier to read. From hosking at elego.de Thu Mar 11 06:40:22 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:40:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054022.EDCE42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:40:22 Modified files: cm3/m3-sys/m3front/src/builtinWord/: Insert.mg Log message: Make use of insert_n and insert_mn. This allows simplified range checking for constant m/n. From hosking at elego.de Thu Mar 11 06:42:06 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 11 Mar 2010 6:42:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311054206.B81732474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/11 06:42:06 Modified files: cm3/m3-sys/m3middle/src/: M3CG.m3 M3CG_BinWr.m3 M3CG_Check.m3 M3CG_Ops.i3 M3CG_Wr.m3 cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Make arguments to insert_mn insert_n extract_mn extract_n CARDINAL. From jkrell at elego.de Thu Mar 11 16:29:14 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 11 Mar 2010 16:29:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311152914.4E6AC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/11 16:29:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: stop outputing lines that end in just \r (unless caller actually gave us such a thing, which they don't) so I can stop dismissing this very annoying messagebox that also pauses to beep: --------------------------- Microsoft Developer Studio --------------------------- Lines ending with only a carriage return have been detected. These will be modified to include a line feed. --------------------------- OK --------------------------- This was occuring every time I open foo.molog, which is produced by cm3 -debug which I use heavily these days. related, most uses of Target.EOL should be Wr.EOL but that isn't changed here. From rcoleburn at elego.de Fri Mar 12 00:55:52 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 0:55:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100311235552.F0BC62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 00:55:52 Modified files: cm3/scripts/install/windows/: cm3CommandShell.CMD Log message: Add features to look for root of cm3 installation in location of currently running CMD script, then in folders on PATH environment variable, before defaulting to "%SystemDrive%\cm3". Of course the "Root path" argument can still be used to force a specific location.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 01:26:19 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 1:26:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312002619.5E20F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 01:26:19 Modified files: cm3/scripts/dev/windows/: RCC_upgradeCM3.cmd Log message: Add feature to search PATH env var as a last resort when trying to locate the root of the cm3 installation.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 04:27:46 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 4:27:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312032746.A46BC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 04:27:46 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Implement quick-fix for problem documented in Trac ticket #1082. The quick-fix is to change the default behavior on Windows such that CM3IDE does not terminate when the browser terminates. I've commented this quick-fix patch in the source code to make it easy to remove if/when we come up with a better solution. Note that if you already have a CM3_IDE.cfg file, it will need to be edited manually for the "start_browser" function, or you can just delete it and CM3IDE will recreate it using the new defaults the next time it runs. This quick-fix patch has no effect on non-Windows systems.--R.Coleburn From rcoleburn at elego.de Fri Mar 12 07:03:44 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Fri, 12 Mar 2010 7:03:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312060344.897122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/12 07:03:44 Modified files: cm3/m3-sys/cm3ide/src/misc/: ConfigItem.m3 Log message: Repair bug introduced with quick-fix patch.--R.Coleburn From jkrell at elego.de Fri Mar 12 12:04:12 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:04:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110412.6C4812474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:04:12 Modified files: cm3/m3-sys/m3back/src/: Stackx86.i3 Stackx86.m3 Log message: insert/extract offset/count INTEGER => CARDINAL, mostly From jkrell at elego.de Fri Mar 12 12:07:36 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:07:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110736.D5C882474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:07:36 Modified files: cm3/m3-sys/m3middle/src/: M3CG_BinRd.m3 M3CG_Wr.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:09:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:09:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312110928.3CD8D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:09:28 Modified files: cm3/m3-sys/m3front/src/misc/: WebInfo.m3 cm3/m3-sys/m3front/src/values/: Module.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111400.E06592474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:00 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Utils.m3 WebFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:14:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:14:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111458.1D8A92474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:14:58 Modified files: cm3/m3-sys/m3middle/src/: M3CG_Rd.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:16:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:16:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111643.5CD652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:16:43 Modified files: cm3/m3-sys/m3linker/src/: MxGen.m3 MxOut.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:19:25 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:19:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312111925.4EA6A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:19:25 Modified files: cm3/m3-sys/m3loader/src/WIN32/: M3LoaderRd.m3 Log message: account for file size now being LONGINT and cast (VAL) to INTEGER From jkrell at elego.de Fri Mar 12 12:26:34 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112634.6324D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:34 Modified files: cm3/m3-sys/m3loader/src/: Main.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:26:58 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:26:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312112658.E9A252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:26:58 Modified files: cm3/m3-sys/m3tests/src/c1/c130/: OWr.m3 Log message: TextF no longer exists (this directory fails to compile for other reasons though) From jkrell at elego.de Fri Mar 12 12:30:17 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:30:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113017.A525D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:30:17 Modified files: cm3/m3-sys/m3objfile/src/: MasmObjFile.m3 Log message: Target.EOL => Wr.EOL From jkrell at elego.de Fri Mar 12 12:34:28 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:34:28 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113428.E15362474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:34:28 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:36:00 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:36:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113600.D3D352474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:36:00 Modified files: cm3/m3-sys/cm3/test/src/: t.m3 Log message: "\n" => Wr.EOL From jkrell at elego.de Fri Mar 12 12:38:51 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:38:51 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312113851.7CAB22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:38:51 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 M3Build.m3 Utils.i3 Utils.m3 Log message: CopyText => Copy just copy files directly no end of line conversion From jkrell at elego.de Fri Mar 12 12:40:09 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:40:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114010.08CE02474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:40:09 Modified files: cm3/m3-sys/cm3/src/: Builder.m3 Log message: remove text_file: BOOLEAN parameter from PROCEDURE PullForBootstrap From jkrell at elego.de Fri Mar 12 12:42:14 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:42:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114214.614572474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:42:14 Modified files: cm3/m3-sys/m3middle/src/: M3File.i3 M3File.m3 Log message: remove PROCEDURE CopyText that does newline conversion From jkrell at elego.de Fri Mar 12 12:43:55 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:43:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114355.854482474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:43:55 Modified files: cm3/m3-sys/m3middle/src/: Target.i3 Target.m3 Log message: remove Target.EOL From jkrell at elego.de Fri Mar 12 12:44:43 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:44:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114443.5D53C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:44:43 Modified files: cm3/m3-sys/m3tests/src/: m3makefile Log message: add feature so cm3 -Ddebug passes -debug down to the test cases -- they'll never pass that way, but extra information is generated that might be useful From jkrell at elego.de Fri Mar 12 12:46:10 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 12 Mar 2010 12:46:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100312114610.A20E42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/12 12:46:10 Modified files: cm3/m3-sys/m3middle/src/: Target.m3 Log message: remove commented code for 32bit LONGINT that catered to older m3back From rcoleburn at elego.de Sat Mar 13 02:11:24 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 2:11:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313011125.34CF12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 02:11:24 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn From jay.krell at cornell.edu Sat Mar 13 05:47:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 04:47:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313011125.34CF12474001@birch.elegosoft.com> References: <20100313011125.34CF12474001@birch.elegosoft.com> Message-ID: This change is suspicious. I think it leaks. Please see http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/FSWin32.m3?rev=1.7;content-type=text%2Fplain for the pattern that is usually used. Granted, given the conservativeness of the collector -- it finds stuff in registers and the stack without a need for metadata telling it where the points are, and the fact that we no longer have VM-synchronization, I don't understand the need for the usual pattern. Maybe because it is willing to move stuff? Therefore a non-traced copy is made for C that won't ever move? - Jay > Date: Sat, 13 Mar 2010 02:11:24 +0000 > To: m3commit at elegosoft.com > From: rcoleburn at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: rcoleburn at birch. 10/03/13 02:11:24 > > Modified files: > cm3/examples/calling-c-win32/src/: OK.m3 > > Log message: > M3toC.TtoS has been renamed to M3toC.SharedTtoS, so make adjustments to Ok.m3 so that it will compile.--R.Coleburn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at elego.de Sat Mar 13 06:57:59 2010 From: rcoleburn at elego.de (Randy Coleburn) Date: Sat, 13 Mar 2010 6:57:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313055759.BFEA82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/03/13 06:57:59 Modified files: cm3/examples/calling-c-win32/src/: OK.m3 Log message: Improve this example code by following the prescribed pattern of freeing the shared storage after it is no longer needed.--R.Coleburn From jkrell at elego.de Sat Mar 13 11:09:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 11:09:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313100917.133702474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 11:09:17 Added files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 m3makefile Log message: This program endeavors to exercise every sort of integer, float, address comparison, and some set compares, in order to support cleanup and improvement of comparison in m3back. If this isn't fleshed out further, it really belongs in the "c for code" test section. From jkrell at elego.de Sat Mar 13 13:12:34 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:12:34 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313121234.2D2122474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:12:34 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add the various no overlap and minimal overlap cases that is: no_overlap_less: [0..1] compared to [2..3] no overlap greater: [2..3] compared to [0..1] min overlap less: [0..1] compared to [1..2] min overlap greater: [1..2] compared to [0..1] I have all these optimized for <, >, <=, >= where possible. Not yet = and #. Only for integer and longint, subranges, not yet for enums, not tested for constants. From jkrell at elego.de Sat Mar 13 13:25:25 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:25:25 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313122525.A06652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:25:25 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: add enum cases From jkrell at elego.de Sat Mar 13 13:32:08 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123208.5933B2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:08 Added files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 m3makefile Log message: a seperate test from p232: This program endeavors to exercise comparisons for subranges and enums that don't overlap or overlap only at the edge. This should probably be in the "c for code" section. What is being tested is that many of these functions return just a constant TRUE or FALSE. From jkrell at elego.de Sat Mar 13 13:32:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 13:32:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313123236.BC2BE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 13:32:36 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: remove (most of) what was moved to p233 From jkrell at elego.de Sat Mar 13 14:16:50 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:16:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313131650.95B082474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:16:50 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add comparisons of CARDINAL to -1 and -2 It looks like I have this all working, except for: <*UNUSED*>PROCEDURE AddressLT0(a:ADDRESS):BOOLEAN=BEGIN RETURN a= NIL because min/max of address is 0/-1, instead 0/2^^32 or 2^^64 perhaps the signedness of address isn't so well defined and this should be left alone anyway. From jkrell at elego.de Sat Mar 13 14:36:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:36:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313133632.5FD172474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:36:32 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: add the unusual case of single element subranges (two variables of such type are always equal, etc. (never not equal, always less-or-equal, always greater-or-equal, never less, never greater), and add comments From jkrell at elego.de Sat Mar 13 14:45:59 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 14:45:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313134559.5F7DC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 14:45:59 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: Fairly simple analysis to optimize comparison of subranges that either don't overlap at all, or only "on the edge" ("on the edge" means the max of one is equal to the min of the other or vice versa) I don't presume that this really helps much real world code, but it is pretty simple so shouldn't hurt. Probably it is rare to mix unequal subranges, let alone non-overlapping or barely overlapping, as well probably rare to compare subranges to constants outside the subrange (or again, "on the edge") This handles, integers, longints, enums, constants, but addresses don't work e.g. address < NIL should perhaps always be false. It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? I was surprised to see that they are separate. It also seemed odd to have to call ConstValue before GetBounds. Backends are not directly given the information for them to do this work, though more advanced analysis might regain the information. subranges and enums just end up as generally unbounded int32, etc. (backends do see range checks and can remember what they imply but I believe parameters are not range checked upon receipt, for example) see test case p233 (though it should probably move to the "c for code" section, since running it doesn't do anything, one reads the code and notices that many of the functions are optimized to just return a constant true or false) This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) compares in m3back, which has a pretty non-optimal implementation. From jay.krell at cornell.edu Sat Mar 13 14:47:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 13:47:57 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313134559.5F7DC2474001@birch.elegosoft.com> References: <20100313134559.5F7DC2474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 14:45:59 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 14:45:59 > > Modified files: > cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 > > Log message: > Fairly simple analysis to optimize comparison of subranges > that either don't overlap at all, or only "on the edge" > ("on the edge" means the max of one is equal to the min of the other > or vice versa) > > I don't presume that this really helps much real world code, but > it is pretty simple so shouldn't hurt. > Probably it is rare to mix unequal subranges, let alone non-overlapping > or barely overlapping, as well probably rare to compare subranges to > constants outside the subrange (or again, "on the edge") > > This handles, integers, longints, enums, constants, but addresses don't work > e.g. address < NIL should perhaps always be false. > > It seems to me that maybe EqualExpr.m3 and CompareExpr.m3 could be combined somehow? > I was surprised to see that they are separate. > > It also seemed odd to have to call ConstValue before GetBounds. > > Backends are not directly given the information for them to do this work, though > more advanced analysis might regain the information. > subranges and enums just end up as generally unbounded int32, etc. > (backends do see range checks and can remember what they imply but > I believe parameters are not range checked upon receipt, for example) > > see test case p233 (though it should probably move to the "c for code" section, > since running it doesn't do anything, one reads the code and notices that > many of the functions are optimized to just return a constant true or false) > > This is actually fallout/tangent from not-yet-done work to optimize integer (and possibly other) > compares in m3back, which has a pretty non-optimal implementation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 15:16:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:16:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313141602.EC5932474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:16:02 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: more test cases, some succeed (at being optimized), some do not. ORD(enum) vs. negative; these work ABS vs. negative; these work ABS vs. 0; these work -ABS vs. cardinal; the only optimizable case is neg_abs_vs_cardinal_GT and it doesn't work -ABS vs. 0; ditto -ABS vs. 1; many optimizable cases, none work ABS has a min of 0 negate of abs should have a max of 0 but is considered unbounded it looks like bounds do not propagate always as they could From jkrell at elego.de Sat Mar 13 15:27:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:27:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313142730.87A5D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:27:30 Modified files: cm3/m3-sys/m3tests/src/p2/p232/: Main.m3 Log message: use interface Word, Long to get unsigned operations (I think they should have EQ/NE, instead of teahing people that they are the same as the signed operations..) From jkrell at elego.de Sat Mar 13 15:40:21 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:40:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313144021.E917A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:40:21 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove some uninteresting cases From jkrell at elego.de Sat Mar 13 15:55:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 15:55:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313145540.F15B72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 15:55:40 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp is not reachable (and this isn't related to generalizations in m3middle/m3cg either; it is about a generalization m3back makes mapping a parameter to a larger set and then optimizing the newer values, none of which can ever occur) From jay.krell at cornell.edu Sat Mar 13 15:57:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 14:57:39 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313145540.F15B72474001@birch.elegosoft.com> References: <20100313145540.F15B72474001@birch.elegosoft.com> Message-ID: small diff attached, with whitespace ignored (as an IF was removed) more coming in this area soon.. > Date: Sat, 13 Mar 2010 15:55:40 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 15:55:40 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > remove some dead code: this 'tozero' stuff in intregcmp and fltregcmp > is not reachable (and this isn't related to generalizations > in m3middle/m3cg either; it is about a generalization m3back > makes mapping a parameter to a larger set and then optimizing > the newer values, none of which can ever occur) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sat Mar 13 19:11:14 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 13 Mar 2010 19:11:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100313181114.B14E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/13 19:11:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 Log message: improve all integer compares, some/all set compares not yet: float compares old pattern: cmp setcc byte in memory xor reg,reg (any register, I believe) mov reg, memory new patterns, depending on comparison/types: xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} cmp setcc reg or cmp possibly with operands reversed sbb reg, reg neg reg or cmp possibly with operands reversed sbb reg, reg inc reg There is a little extra pressure on eax,ebx,ecx,edx, but we save an instruction and we avoid use of an in-memory temporary. The instruction could have been saved by using movzx as the manuals recommend anyway, instead of xor+mov. The sequences are used are based on optimized C. Basic problem here is setcc which only sets a byte but we generally want 32bit values. Possibly more to do here. The main difficulty developing this change was that I didn't initially restrict to RegistersForByteOperations. Small test cases worked ok but cases with more register pressure did not. see test p232 for a test that currently exercises some of this. From jay.krell at cornell.edu Sat Mar 13 19:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 13 Mar 2010 18:12:21 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100313181114.B14E22474001@birch.elegosoft.com> References: <20100313181114.B14E22474001@birch.elegosoft.com> Message-ID: diff attached > Date: Sat, 13 Mar 2010 19:11:14 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/13 19:11:14 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Stackx86.m3 > > Log message: > improve all integer compares, some/all set compares > not yet: float compares > > old pattern: > cmp > setcc byte in memory > xor reg,reg (any register, I believe) > mov reg, memory > > new patterns, depending on comparison/types: > xor reg, reg (register restricted to RegistersForByteOperations = {EAX, EBX, ECX, EDX} > cmp > setcc reg > > or > cmp possibly with operands reversed > sbb reg, reg > neg reg > > or > cmp possibly with operands reversed > sbb reg, reg > inc reg > > There is a little extra pressure on eax,ebx,ecx,edx, but > we save an instruction and we avoid use of an in-memory temporary. > The instruction could have been saved by using movzx as the manuals > recommend anyway, instead of xor+mov. > > The sequences are used are based on optimized C. > > Basic problem here is setcc which only sets a byte > but we generally want 32bit values. > > Possibly more to do here. > > The main difficulty developing this change was > that I didn't initially restrict to RegistersForByteOperations. > Small test cases worked ok but cases with more register pressure did not. > see test p232 for a test that currently exercises some of this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Sun Mar 14 06:29:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 6:29:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314052940.11B272474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 06:29:39 Modified files: cm3/m3-sys/m3front/src/exprs/: CompareExpr.m3 EqualExpr.m3 Log message: go back a version the codegen optimization is ok, but I confused "semantically const" with "opportunistically const" e.g. the following is not legal C: const int a = 1; /* ok */ const int b = a + 1; /* not ok */ int c[a]; /* not ok */ int F() { return 1; } /* ok */ int d = F(); /* not ok */ int e[F()]; /* not ok */ (I'm assuming c89 or such, not c9x.) compiler could optimize: int F1() { return 1; } int F2() { return F() + F1(); } /* => return 2 */ but that occurs "differently". From jkrell at elego.de Sun Mar 14 07:31:23 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 7:31:23 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314063123.8DFA52474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 07:31:23 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: start removing cases that don't work and annotating function names with their expected constant value From jkrell at elego.de Sun Mar 14 11:38:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 11:38:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314103811.E03C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 11:38:11 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove unused import word/long From jkrell at elego.de Sun Mar 14 12:42:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 12:42:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314114239.6B9612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 12:42:39 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: remove more uninteresting cases, label all cases with expected value; a properly modified cm3 should issue a warning for each procedure From jkrell at elego.de Sun Mar 14 13:35:52 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 13:35:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314123552.C26EA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 13:35:52 Modified files: cm3/m3-sys/m3tests/src/p2/p233/: Main.m3 Log message: call every function and verify they return the right value (which wasn't really ever the point, they always compiled correctly, just inefficiently From jkrell at elego.de Sun Mar 14 14:00:32 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 14:00:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314130032.4838D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 14:00:32 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: remove three dead lines left over from when 64bit shifts weren't inlined From jkrell at elego.de Sun Mar 14 16:42:40 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 16:42:40 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314154240.673312474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 16:42:40 Added files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: initial copy of Atomic.mg, this version won't have all the switch statements From jkrell at elego.de Sun Mar 14 17:02:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:02:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314160230.D13612474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:02:30 Modified files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg atomic.tmpl m3makefile Log message: provide a version without a bunch of code from switch statements, esp. for platforms that only have sequential memory models (note that x86 with lfense/sfence/mfence/whatever can do better) From jkrell at elego.de Sun Mar 14 17:18:30 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:18:30 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314161830.4E70C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:18:30 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "t" is usually for "type", spell it out (sometimes it is for text) From jkrell at elego.de Sun Mar 14 17:21:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 17:21:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314162107.9E4042474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 17:21:04 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: 'z' is apparently for "type_that_is_a_multiple_of_32bits" spell it out too; maybe a shorter name can be found but I don't think 'z' is it. From jay.krell at cornell.edu Sun Mar 14 17:35:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 16:35:10 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314162107.9E4042474001@birch.elegosoft.com> References: <20100314162107.9E4042474001@birch.elegosoft.com> Message-ID: Maybe "z" is for "zero extended"? - Jay > Date: Sun, 14 Mar 2010 17:21:04 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 17:21:04 > > Modified files: > cm3/m3-sys/m3back/src/: M3x86.m3 > > Log message: > 'z' is apparently for "type_that_is_a_multiple_of_32bits" > spell it out too; maybe a shorter name can be found > but I don't think 'z' is it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:23:42 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:23:42 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314172342.E94E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:23:42 Modified files: cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 Stackx86.m3 Log message: flesh out all the atomic operations, including 8, 16, and 64 bit operations There's some improvement to be had here still. Mainly that we overuse interlocked compare exchange loops. Some operations don't need that, e.g. add, sub, xor. Sometimes even "or" and "and" don't need them either, but we aren't likely to have sufficient context to discover that. In particular, if caller throws out the returned old value, then a direct "lock or" or "lock and" instruction can be used, instead of an interlocked compare exchange. Compare the code to these two functions: char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is just two instructions including the ret. The first contains a loop. Also we might be able to get the zero flag more efficiently for some cases, e.g. the non-64 bit cases. We can xor a register up front, sete it, and mov into eax, instead of going through memory (same number of instructions probably, and increased register pressure). Also register allocater (procedure find) should get an explicit flag to force the ecx:ebx allocation (and edx:eax). We should also try inlined tests, as opposed to interface atomic, and verify we don't unnecessarily enregister the atomic variable's address. That is needed in testing so far since I've just been looking at m3core. (ie: more testing, not just looking at m3core) We should also perhaps implement looser load/store where we only have a barrier on one side instead of both. Presently every atomic load/store is both preceded and followed by a serializing xchg. We should also consider if the barrier variable should be one widely shared global instead of everyone having to waste 4 bytes of stack for it. Note that AtomicLongint__Swap doesn't return the right value currently. Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? Kind of like the funny thing AtomicLongint__Swap does? (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary value for the first try: 0). That is to say, AtomicLongint__Load/Store are not presently atomic! No other correctness problems known. From jay.krell at cornell.edu Sun Mar 14 18:28:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314172342.E94E22474001@birch.elegosoft.com> References: <20100314172342.E94E22474001@birch.elegosoft.com> Message-ID: > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jay.krell at cornell.edu Sun Mar 14 18:31:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Mar 2010 17:31:53 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314172342.E94E22474001@birch.elegosoft.com>, Message-ID: searched the web: http://niallryan.com/node/137 shows 64 bit atomic read/write on x86. Including using floating point to do it..is it right? I'm inclined to implement the non-fp method. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sun, 14 Mar 2010 17:28:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 > Note that AtomicLongint__Swap doesn't return the right value currently. I think I fixed that. It was just a typo ECX vs. EDX. Diff attached. I'm still thinking about how to do atomic 64 bit load/store. I'm not sure it is possible. Tony, please notice: > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } vs. > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } The second is way more efficient, like, if you can inform the backend that the caller throws out the return value. The second is ret plus one instruction. The first contains a loop. - Jay > Date: Sun, 14 Mar 2010 18:23:42 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 18:23:42 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > Stackx86.m3 > > Log message: > flesh out all the atomic operations, > including 8, 16, and 64 bit operations > > There's some improvement to be had here still. > > Mainly that we overuse interlocked compare exchange loops. > Some operations don't need that, e.g. add, sub, xor. > Sometimes even "or" and "and" don't need them either, but > we aren't likely to have sufficient context to discover that. > In particular, if caller throws out the returned old value, > then a direct "lock or" or "lock and" instruction can be used, > instead of an interlocked compare exchange. > > Compare the code to these two functions: > > char __fastcall or8(char* a, char b) { return _InterlockedOr8(a,b); } > void __fastcall or8(char* a, char b) { _InterlockedOr8(a,b); } > > The second is just two instructions including the ret. > The first contains a loop. > > Also we might be able to get the zero flag more > efficiently for some cases, e.g. the non-64 bit cases. > We can xor a register up front, sete it, and mov into eax, > instead of going through memory (same number of instructions > probably, and increased register pressure). > > Also register allocater (procedure find) should get an explicit > flag to force the ecx:ebx allocation (and edx:eax). > > We should also try inlined tests, as opposed to interface atomic, > and verify we don't unnecessarily enregister the atomic variable's address. > That is needed in testing so far since I've just been looking at m3core. > (ie: more testing, not just looking at m3core) > > We should also perhaps implement looser load/store where we only > have a barrier on one side instead of both. > Presently every atomic load/store is both preceded and followed by a serializing xchg. > > We should also consider if the barrier variable should be one widely > shared global instead of everyone having to waste 4 bytes of stack for it. > > Note that AtomicLongint__Swap doesn't return the right value currently. > > Note that AtomicLongint__Load/Store should maybe use interlocked compare exchange loop? > Kind of like the funny thing AtomicLongint__Swap does? > (AtomicLongint__Swap uses interlocked compare exchange, but picks an arbitrary > value for the first try: 0). > > That is to say, AtomicLongint__Load/Store are not presently atomic! > > No other correctness problems known. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Sun Mar 14 18:41:02 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:41:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174108.9D8772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:41:02 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Load per http://niallryan.com/node/137 some cleanup AtomicLongint__Store not right yet From jkrell at elego.de Sun Mar 14 18:42:27 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 18:42:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314174227.AC1C82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 18:42:27 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: "type_that_is_a_multiple_of_32bits" => "type_multiple_of_32" It is a bit shorter. We'll see how it goes. From jkrell at elego.de Sun Mar 14 19:11:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:11:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181119.4468E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:11:14 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: fix AtomicLongint__Store to be atomic see http://niallryan.com/node/137 I use the lock cmpxhg8b method, not the float method. Note that all the AtomicLongint functions require a "new" processor. From jkrell at elego.de Sun Mar 14 19:13:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:13:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181311.545C42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:13:11 Modified files: cm3/m3-sys/m3back/src/: M3x86.m3 Log message: Preserve signedness a bit: 'Word64' => 'type' Probably doesn't matter. From jkrell at elego.de Sun Mar 14 19:17:43 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 14 Mar 2010 19:17:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314181743.7795F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/14 19:17:43 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: add CompareOpNames From hosking at cs.purdue.edu Sun Mar 14 19:31:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 14:31:35 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314154240.673312474001@birch.elegosoft.com> References: <20100314154240.673312474001@birch.elegosoft.com> Message-ID: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! On 14 Mar 2010, at 16:42, Jay Krell wrote: > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/14 16:42:40 > > Added files: > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > Log message: > initial copy of Atomic.mg, this version won't have all the switch statements From hosking at elego.de Sun Mar 14 19:35:10 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:35:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314183510.9AAF22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:35:10 Modified files: cm3/m3-libs/m3core/src/atomic/: atomic.tmpl m3makefile Removed files: cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg Log message: Remove premature and irrational optimization. The compiler inlines the non-switch versions. There is no need for this overspecialization. From hosking at elego.de Sun Mar 14 19:49:31 2010 From: hosking at elego.de (Antony Hosking) Date: Sun, 14 Mar 2010 19:49:31 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100314184932.1A1AE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/14 19:49:31 Modified files: cm3/m3-sys/m3middle/src/: M3CG.i3 Log message: No-one uses the strings. From jay.krell at cornell.edu Mon Mar 15 02:44:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:44:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> References: <20100314154240.673312474001@birch.elegosoft.com>, <81324180-29DF-4B66-9635-A521B078673E@cs.purdue.edu> Message-ID: The generated code was awful otherwise. All these big switch statements, only to do the same thing in each one. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 14 Mar 2010 14:31:35 -0400 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > What is the point of this?????????!!!!!!!!!!!!!!!!!!!!!! > > On 14 Mar 2010, at 16:42, Jay Krell wrote: > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/03/14 16:42:40 > > > > Added files: > > cm3/m3-libs/m3core/src/atomic/: AtomicSequential.mg > > > > Log message: > > initial copy of Atomic.mg, this version won't have all the switch statements > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:45:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:45:37 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100314184932.1A1AE2474001@birch.elegosoft.com> References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Mar 15 02:47:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 14 Mar 2010 21:47:25 -0400 Subject: [M3commit] CVS Update: cm3 In-Reply-To: References: <20100314184932.1A1AE2474001@birch.elegosoft.com> Message-ID: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: > I was using them. It is easy to imagine they'll be used again, while debugging. > > - Jay > > > Date: Sun, 14 Mar 2010 19:49:31 +0000 > > To: m3commit at elegosoft.com > > From: hosking at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: hosking at birch. 10/03/14 19:49:31 > > > > Modified files: > > cm3/m3-sys/m3middle/src/: M3CG.i3 > > > > Log message: > > No-one uses the strings. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Mar 15 02:54:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 01:54:59 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> References: <20100314184932.1A1AE2474001@birch.elegosoft.com>, , <97AA49A0-F13F-47FB-B479-D710FE0297B3@cs.purdue.edu> Message-ID: I removed them once I got my code working. But we have this sort of thing in general. - Jay From: hosking at cs.purdue.edu Date: Sun, 14 Mar 2010 21:47:25 -0400 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 Where, I didn't see references. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 14 Mar 2010, at 21:45, Jay K wrote: I was using them. It is easy to imagine they'll be used again, while debugging. - Jay > Date: Sun, 14 Mar 2010 19:49:31 +0000 > To: m3commit at elegosoft.com > From: hosking at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: hosking at birch. 10/03/14 19:49:31 > > Modified files: > cm3/m3-sys/m3middle/src/: M3CG.i3 > > Log message: > No-one uses the strings. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkrell at elego.de Mon Mar 15 03:29:38 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:29:38 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315022938.9D22A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:29:38 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: Fill in *a lot* more now that m3back implements everything. Notice that a few Refany cases are commented out, I couldn't figure out a way to call them (inc, dec, or, xor, and). From jkrell at elego.de Mon Mar 15 03:33:06 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:33:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315023307.9A5B62474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:33:06 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: return rather than just eval IsLockFree() From jkrell at elego.de Mon Mar 15 03:40:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 3:40:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315024017.886B22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 03:40:16 Modified files: cm3/m3-sys/m3tests/src/p2/p226/: Main.m3 Log message: just one fence per fence test From jkrell at elego.de Mon Mar 15 10:55:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 10:55:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315095514.B7E772474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 10:55:14 Modified files: cm3/scripts/python/: pylib.py Log message: fix long standing problem where do-pkg.py doesn't correctly order (or filter) packages given on command line From jkrell at elego.de Mon Mar 15 11:44:24 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 11:44:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315104424.0A2202474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 11:44:24 Modified files: cm3/scripts/python/: do-cm3-all.py do-cm3-min.py do-cm3-std.py make-dist.py pylib.py Log message: order packages (some scenarios already did, but some did not) support package groups this makes do-pkg.py basically like do-cm3.cmd read scripts/pkginfo.txt instead of using local copy From jkrell at elego.de Mon Mar 15 14:20:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:20:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132035.6D8F22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:20:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. safekeeping: don't save/restore non-volatile registers we don't use This attemps to defer the saving until use, however that appears to be a losing attempt due to branches. Better is to add another pass or some "fixup" so we can do whatever saving is needed in the prologue, but only what is needed. Compromise will be nop out the unneeded pushes, and omit the pops, of course. From jkrell at elego.de Mon Mar 15 14:23:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 14:23:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315132311.718CA2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 14:23:11 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: go back a version: just always/save restore all 3 non-volatiles a compromise shortly that saves up front, possibly nop-ing out, and only restores what is needed From jkrell at elego.de Mon Mar 15 15:35:50 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:35:50 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143550.C8D2D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:35:50 Modified files: cm3/m3-sys/m3objfile/src/: NTObjFile.m3 M3ObjFile.i3 Log message: provide a function 'backup()' that lets caller seek backwards from the cursor; this should afford m3back something cleaner in generating epilogues, though still not great From jkrell at elego.de Mon Mar 15 15:36:11 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:36:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315143612.04DFD2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:36:11 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: don't compile MasmObjFile, it isn't used From jkrell at elego.de Mon Mar 15 15:40:14 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 15:40:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315144014.C608D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 15:40:14 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 Log message: Do something cleaner when generating prologues. In the interest of an optimization that saves an instruction from many many (all?) functions, the original authors often produce an epilogue by punching through abstraction boundaries and using objfile.patch. Worse, they sometimes do that, sometimes use equivalent code that goes through the layers. With this change, instead, we backup(5) and then use the clearer version. Unfortunately, if nothing else done, that leaves us trying to fixup the branch that we wiped out (its use of the label to the end of function. So compensate slightly in Codex86.m3. This is trading one ugliness for another. Perhaps something better can be found. I had something that compared to last_exitbranch in codex86.m3 but that wasn't quite right and introduced e.g. one instruction difference in RTHeapMap.m3. From jkrell at elego.de Mon Mar 15 16:06:35 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:06:35 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315150635.6BAF82474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:06:35 Modified files: cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 Stackx86.m3 Log message: Remove from one to three instructions from small functions. By tracking which non-volatile registers are used and only saving/restoring them. Unfortunately, until we are more sophisticated, we have to pay for the size for the push instructions, but we nop them out if they aren't needed, and only generating the needed pops. (We should look into two and three byte nops, but presently I just use one byte nops. The pushes are each one instruction. Theoretically, nop is faster than push, though I should check. Plus, nop saves us from doing a pop.) Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. Register allocator should probably favor volatile registers over non-volatile. Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) I noticed an ancient bug in doing this work. Functions with >4K frames need to call chkstk or equivalent. Specifically, stack pages must be touched in order. call naturally touches a page. Or, side motivation: match what the C compiler does. It is correct. (See, we also reserve room for sub esp,foo, for 32bit foo, even though many functions save save 3 bytes and use an 8bit value and some unusual functions can skip the entire thing (if foo = 0)) We can issue errors for such functions and see if any turn up. See test case p234 (not commited yet). Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. corrupt, set_reg, movop1, load_ind should suffice. From jkrell at elego.de Mon Mar 15 16:12:36 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:12:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315151237.264CF2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:12:36 Added files: cm3/m3-sys/m3tests/src/p2/p234/: Main.m3 m3makefile Log message: add test that uses or doesn't use non-volatile registers perhaps should be moved to the "c for code" section We run it, make sure it doesn't crash, but the real point is codegen details. From jay.krell at cornell.edu Mon Mar 15 16:15:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Mar 2010 15:15:12 +0000 Subject: [M3commit] CVS Update: cm3 In-Reply-To: <20100315150635.6BAF82474001@birch.elegosoft.com> References: <20100315150635.6BAF82474001@birch.elegosoft.com> Message-ID: diff attached, it is pretty simple > Date: Mon, 15 Mar 2010 16:06:35 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/03/15 16:06:35 > > Modified files: > cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 > Stackx86.m3 > > Log message: > Remove from one to three instructions from small functions. > By tracking which non-volatile registers are used and only saving/restoring them. > Unfortunately, until we are more sophisticated, we have to pay for the size > for the push instructions, but we nop them out if they aren't needed, > and only generating the needed pops. (We should look into two and three > byte nops, but presently I just use one byte nops. The pushes are each > one instruction. Theoretically, nop is faster than push, though I should check. > Plus, nop saves us from doing a pop.) > > Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now. > > Register allocator should probably favor volatile registers over non-volatile. > Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet) > > I noticed an ancient bug in doing this work. > Functions with >4K frames need to call chkstk or equivalent. > Specifically, stack pages must be touched in order. call naturally > touches a page. Or, side motivation: match what the C compiler does. It is correct. > (See, we also reserve room for sub esp,foo, for 32bit foo, even > though many functions save save 3 bytes and use an 8bit value and > some unusual functions can skip the entire thing (if foo = 0)) > > We can issue errors for such functions and see if any turn up. > > See test case p234 (not commited yet). > > Use of the new proc_reguse is sprinkled in a bit unnecessarily much here. > corrupt, set_reg, movop1, load_ind should suffice. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 1.txt URL: From jkrell at elego.de Mon Mar 15 16:26:08 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 16:26:08 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315152608.D59162474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 16:26:08 Modified files: cm3/m3-sys/m3back/src/: Stackx86.m3 Log message: Be certain to get the register allocation correct for 64bit interlocked compare exchange. The code could be reduced but is very clear this way. We should probably have special flags (Force values) for ret64 (return_double_integer) as well as interlocked compare exchange double integer parameters. For now I infer these cases from aspects that could occur in less constrained situations, leading to unnecessary register moves (i.e. if we already for some reason have something in EAX:EDX, we shouldn't change it to EDX:EAX unless we actually have to.) From jkrell at elego.de Mon Mar 15 23:21:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 15 Mar 2010 23:21:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100315222155.833692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/15 23:21:55 Added files: cm3/m3-sys/m3back/src/doc/: frames.txt Log message: some notes on current, ideal, and correct patterns, based on C compiler output What we have is usually correct, rarely ideal, and sometimes wrong. In particular, we are not ideal for common case of functions with fewer than 128 bytes of locals. We use a 4 byte constant where a 1 byte constant suffices. Or the unusual cases of no locals/parameters. We are wrong for functions with more than 4K of locals: need to call chkstk. Let's at least try to fix the second case soon, but without making the usual cases larger. From jkrell at elego.de Tue Mar 16 11:37:59 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:37:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316103800.04B492474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:37:59 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: write debug output integers the old way: the new way isn't so important any longer, and it looks like this format *might* be readable From jkrell at elego.de Tue Mar 16 11:42:46 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:42:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104247.02FCC2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:42:46 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: fix (looks like I had copied from release?) From jkrell at elego.de Tue Mar 16 11:45:14 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 11:45:14 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316104514.4BE4D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 11:45:14 Modified files: cm3/m3-sys/m3back/src/: Wrx86.m3 Log message: slightly more vertically dense: save two lines From jkrell at elego.de Tue Mar 16 14:27:06 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 14:27:06 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316132706.D92102474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 14:27:06 Modified files: cm3/m3-sys/m3objfile/src/: m3makefile Log message: put back MasmObjFile for m3staloneback From jkrell at elego.de Tue Mar 16 17:29:07 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 16 Mar 2010 17:29:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316162908.048D22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/16 17:29:07 Modified files: cm3/scripts/python/: pylib.py Log message: reasonable hack: ignore package names that end '.py' -- these are argv[0] From wagner at elego.de Tue Mar 16 22:51:59 2010 From: wagner at elego.de (Olaf Wagner) Date: Tue, 16 Mar 2010 22:51:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100316215159.9892F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/16 22:51:59 Modified files: cm3/www/releng/: Tag: release_branch_cm3_5_8 update-releng-index.sh Log message: list Debian and MSI packages, too From jkrell at elego.de Wed Mar 17 17:33:44 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:33:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163344.780D12474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:33:44 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: use fork1() on Solaris in case built/running on pre-Solaris 2.10 and using the libraries in which fork==forkall (at some point should setup a pre 2.10 machine?) From jkrell at elego.de Wed Mar 17 17:35:32 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 17:35:32 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317163532.B486E2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 17:35:32 Modified files: cm3/m3-libs/m3core/src/unix/Common/: UnixC.c Log message: if defined => ifdef in previous From jkrell at elego.de Wed Mar 17 18:02:57 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:02:57 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170257.1CB462474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:02:57 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: for now put back set_member and set_singleton, so I haven't to rebuild everything From jkrell at elego.de Wed Mar 17 18:03:46 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 17 Mar 2010 18:03:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100317170346.8E99C2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/17 18:03:46 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: Longer name for parameter From pmckinna at elego.de Thu Mar 18 11:50:17 2010 From: pmckinna at elego.de (Peter McKinna) Date: Thu, 18 Mar 2010 11:50:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105018.01F342474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: pmckinna at birch. 10/03/18 11:50:17 Modified files: cm3/m3-comm/netobj/tests/perf/src/: m3makefile Log message: Fixed quotes From jkrell at elego.de Thu Mar 18 11:55:48 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 11:55:48 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318105548.99CDE2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 11:55:48 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: cleanup to use and factor out the "safe double free" pattern, e.g. procedure Close(var i) if i >= 0 close(i) i = -1 This does not address the pthreads hangs. From jkrell at elego.de Thu Mar 18 12:12:13 2010 From: jkrell at elego.de (Jay Krell) Date: Thu, 18 Mar 2010 12:12:13 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100318111213.C0B7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/18 12:12:13 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: small part of cvsup fix - initialize stuff in InitActivations instead of depending on static initialization It used to look like this anyway I think. - change some variables to CARDINAL From jkrell at elego.de Fri Mar 19 18:07:59 2010 From: jkrell at elego.de (Jay Krell) Date: Fri, 19 Mar 2010 18:07:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100319170759.3D67D2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/19 18:07:59 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: fix newlines From jkrell at elego.de Sat Mar 20 08:10:45 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:10:45 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320071045.ED2692474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:10:45 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: add back div/mod helpers for compatibility with older backend, I was still using them a while From jkrell at elego.de Sat Mar 20 08:56:10 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:56:10 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075611.0313F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:56:10 Added files: cm3/m3-libs/m3core/src/Csupport/Common/: test_hand.c Log message: add some tests for set_lt, le, gt, le; I find this code a bit hard to understand From jkrell at elego.de Sat Mar 20 08:59:16 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 8:59:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320075916.38C252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 08:59:16 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: implement set_gt(a,b) as set_lt(b,a) implement set_ge(a,b) as set_le(b,a) Really the frontend or backend should make this transform. From jkrell at elego.de Sat Mar 20 09:22:18 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 9:22:18 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320082218.82AA42474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 09:22:18 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test; not seeing commit mail? From jay.krell at cornell.edu Sat Mar 20 09:21:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 20 Mar 2010 08:21:58 +0000 Subject: [M3commit] test Message-ID: test; not seeing commit mail? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mand at elego.de Sat Mar 20 19:20:27 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:20:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182027.3E2762474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:20:27 Modified files: cm3/: README Log message: Trivial text edit for test purposes. Sorry for the spam. From mand at elego.de Sat Mar 20 19:21:58 2010 From: mand at elego.de (Michael Anderson) Date: Sat, 20 Mar 2010 19:21:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320182158.C7A652474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/20 19:21:58 Modified files: cm3/: README Log message: Cleanin up after commit mail test.... From jkrell at elego.de Sat Mar 20 21:40:39 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 20 Mar 2010 21:40:39 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100320204039.993E22474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/20 21:40:39 Added files: cm3/m3-libs/m3core/src/runtime/common/: RTProcessC.c Log message: new file, empty to start From jkrell at elego.de Sun Mar 21 02:35:44 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 2:35:44 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321013545.5C8252474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 02:35:44 Modified files: cm3/m3-libs/m3core/src/Csupport/Common/: hand.c Log message: test commit mail; some recent commits here didn't show up; no diff here From jkrell at elego.de Sun Mar 21 10:28:04 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:04 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092809.55CF72474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:04 Modified files: cm3/scripts/python/: Tag: release_branch_cm3_5_8 pylib.py Log message: fix making Debian packages From jkrell at elego.de Sun Mar 21 10:28:36 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 21 Mar 2010 10:28:36 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100321092836.82E552474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/21 10:28:36 Modified files: cm3/scripts/python/: pylib.py Log message: fix making Debian packages From jkrell at elego.de Mon Mar 22 05:21:54 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 22 Mar 2010 5:21:54 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100322042154.CAA7F2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/22 05:21:54 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTProcess.m3 Log message: remove newlines at end of file From hosking at elego.de Thu Mar 25 02:45:16 2010 From: hosking at elego.de (Antony Hosking) Date: Thu, 25 Mar 2010 2:45:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100325014517.5E98A2474001@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/25 02:45:16 Modified files: cm3/m3-sys/m3front/src/misc/: M3Front.m3 Log message: We have a decent collector. From mand at elego.de Fri Mar 26 22:53:59 2010 From: mand at elego.de (Michael Anderson) Date: Fri, 26 Mar 2010 22:53:59 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100326215400.0AC302474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: mand at birch. 10/03/26 22:53:59 Modified files: cm3/www/: todo.html Log message: Trivial text edit to test after server upgrade. Sorry for the spam. From jkrell at elego.de Sat Mar 27 09:56:15 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:15 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085615.C13DB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:15 Modified files: cm3/m3-tools/cvsup/client/src/: Auth.i3 Auth.m3 BackoffTimer.i3 BackoffTimer.m3 CheckoutCreator.i3 CheckoutCreator.m3 CheckoutUpdater.i3 CheckoutUpdater.m3 Detailer.i3 Detailer.m3 EventSync.i3 EventSync.m3 FSClient.i3 FSClient.m3 FileUpdater.i3 FileUpdater.m3 Fixup.i3 Main.m3 RCSUpdater.i3 RCSUpdater.m3 Receive.i3 Receive.m3 RegularCreator.i3 RegularCreator.m3 RegularUpdater.i3 RegularUpdater.m3 RsyncUpdater.i3 RsyncUpdater.m3 SupFile.i3 SupFile.m3 SupGUI.i3 SupGUI.m3 SupGUIFake.m3 TextPortLogger.i3 TextPortLogger.m3 TextVBTLogger.i3 TextVBTLogger.m3 TreeList.i3 TreeList.m3 Updater.i3 Updater.m3 Version.i3 cm3/m3-tools/cvsup/cvpasswd/src/: Main.m3 Secret.i3 Secret.m3 Upass.i3 cm3/m3-tools/cvsup/server/src/: AccessRules.i3 AccessRules.m3 ClassDB.i3 ClassDB.m3 ClientClass.i3 ClientClass.m3 FSServer.i3 FSServer.m3 FSServerRep.i3 FSServerU.m3 FileInfo.i3 FileInfo.m3 Main.m3 ParsedDelta.i3 ParsedDelta.m3 Passwd.i3 Passwd.m3 RCSComp.i3 RCSComp.m3 TreeComp.i3 TreeComp.m3 Version.i3 cm3/m3-tools/cvsup/suplib/src/: Attic.i3 Attic.m3 AuthMD5.i3 AuthMD5.m3 CText.i3 CVProto.i3 CVProto.m3 CVTree.i3 CVTree.m3 ChannelMux.i3 ChannelMux.m3 DevT.i3 DirEntry.i3 DirEntry.m3 ErrMsg.i3 ErrMsg.m3 EscapedRd.i3 EscapedRd.m3 EscapedWr.i3 EscapedWr.m3 ExecRec.i3 FileAttr.i3 FileAttr.m3 FileAttrRep.i3 FileID.i3 FileID.m3 FileStatus.i3 FileStatus.m3 FileStatusRaw.i3 Glob.i3 Glob.m3 GlobTree.i3 GlobTree.m3 GzipError.i3 GzipError.m3 GzipRd.i3 GzipRd.m3 GzipWr.i3 GzipWr.m3 IOWatchDog.i3 IOWatchDog.m3 LockFile.i3 LockFile.m3 Logger.i3 Logger.m3 LoggerClass.i3 MD5.i3 MD5.m3 MD5Digest.i3 MD5Digest.m3 MD5Wr.i3 MD5Wr.m3 MySyslog.i3 PathComp.i3 PathComp.m3 ProcTitle.i3 RCSAccess.i3 RCSAccess.m3 RCSDate.i3 RCSDate.m3 RCSDelta.i3 RCSDelta.m3 RCSDeltaClass.i3 RCSEdit.i3 RCSError.i3 RCSFile.i3 RCSFile.m3 RCSKeyword.i3 RCSKeyword.m3 RCSPhrase.i3 RCSPhrase.m3 RCSPhrases.i3 RCSPhrases.m3 RCSRevNum.i3 RCSRevNum.m3 RCSString.i3 RCSString.m3 RCSTag.i3 RCSTag.m3 Reaper.i3 Reaper.m3 RsyncBlock.i3 RsyncBlock.m3 RsyncFile.i3 RsyncFile.m3 SigHandler.i3 SigHandler.m3 SplitLogger.i3 SplitLogger.m3 StatusFile.i3 StatusFile.m3 SupFileRec.i3 SupFileRec.m3 SupMisc.i3 SupMisc.m3 SysLogger.i3 SysLogger.m3 TimeStampLogger.i3 TimeStampLogger.m3 TokScan.i3 TokScan.m3 Uglob.i3 Ugzip.i3 Ugzip.m3 UgzipP.i3 Umd5.i3 UnixMisc.i3 UnixMisc.m3 WatchDog.i3 WatchDog.m3 WrLogger.i3 WrLogger.m3 cm3/m3-tools/cvsup/suplib/src/FreeBSD/: FileAttrOS.i3 FileAttrOS.m3 ProcTitle.m3 UProcTitle.i3 cm3/m3-tools/cvsup/suplib/src/POSIX/: FileAttrOS.m3 ProcTitle.m3 cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: DevT.m3 cm3/m3-tools/cvsup/suplib/src/text_cm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suplib/src/text_pm3/: CText.m3 SupMiscText.m3 cm3/m3-tools/cvsup/suptcp/src/POSIX/: SockOpt.i3 SockOptFBSD.m3 SockOptOther.m3 cm3/m3-tools/cvsup/suptcp/src/common/: StreamRd.i3 StreamRdClass.i3 StreamRdClass.m3 StreamWr.i3 StreamWrClass.i3 StreamWrClass.m3 TCPMisc.i3 Log message: remove $Id$, see scripts/python/remove-id.py From jkrell at elego.de Sat Mar 27 09:56:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sat, 27 Mar 2010 9:56:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100327085649.D7D972474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/27 09:56:49 Added files: cm3/scripts/python/: remove-id.py Log message: automate removing $Id$ From jkrell at elego.de Sun Mar 28 01:13:22 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:13:22 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001322.9516B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:13:22 Modified files: cm3/m3-tools/cvsup/: Makefile cm3/m3-tools/cvsup/client/: Makefile cm3/m3-tools/cvsup/client/src/: m3makefile cm3/m3-tools/cvsup/config/src/: m3makefile cm3/m3-tools/cvsup/cvpasswd/: Makefile cm3/m3-tools/cvsup/cvpasswd/src/: m3makefile cm3/m3-tools/cvsup/doc/: Makefile cm3/m3-tools/cvsup/server/: Makefile cm3/m3-tools/cvsup/server/src/: m3makefile cm3/m3-tools/cvsup/suplib/: Makefile cm3/m3-tools/cvsup/suplib/src/: m3makefile cm3/m3-tools/cvsup/suplib/src/FreeBSD/: m3makefile cm3/m3-tools/cvsup/suplib/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suplib/src/dev_t_posix/: m3makefile cm3/m3-tools/cvsup/suplib/src/libglob/: m3makefile cm3/m3-tools/cvsup/suplib/src/libmd/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_cm3/: m3makefile cm3/m3-tools/cvsup/suplib/src/text_pm3/: m3makefile cm3/m3-tools/cvsup/suptcp/: Makefile cm3/m3-tools/cvsup/suptcp/src/: m3makefile cm3/m3-tools/cvsup/suptcp/src/POSIX/: m3makefile cm3/m3-tools/cvsup/suptcp/src/common/: m3makefile Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:15:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:15:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001541.22C9D2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:15:41 Modified files: cm3/m3-tools/cvsup/: Acknowledgments Announce Blurb Install cm3/m3-tools/cvsup/client/src/: SyncQueue.ig SyncQueue.mg cm3/m3-tools/cvsup/doc/: Attributes Checkouts Protocol faqgen.awk cm3/m3-tools/cvsup/examples/: README cm3/m3-tools/cvsup/suplib/src/: Merger.ig Merger.mg UnixMiscC.c cm3/m3-tools/cvsup/suplib/src/libglob/: fnmatch.c fnmatch.h cm3/m3-tools/cvsup/suplib/src/libmd/: md5.h md5c.c cm3/m3-tools/cvsup/suptcp/src/: README cm3/m3-tools/cvsup/suptcp/src/POSIX/: SupTCP.m3 SupTCPHack.i3 SupTCPHack.m3 SupTCPHackNull.m3 SupTCPPosix.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 01:17:01 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 1:17:01 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328001701.646132474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 01:17:01 Modified files: cm3/m3-tools/cvsup/client/src/: SupGUI.fv cvsup.1 syncqueue.tmpl cm3/m3-tools/cvsup/contrib/cvsup2httplog/: cvsup2httplog cm3/m3-tools/cvsup/contrib/cvsupchk/: cvsupchk cm3/m3-tools/cvsup/cvpasswd/src/: cvpasswd.1 cm3/m3-tools/cvsup/quake/: cvsup.quake cm3/m3-tools/cvsup/server/src/: cvsupd.8 cm3/m3-tools/cvsup/suplib/src/: merger.tmpl cm3/m3-tools/cvsup/suplib/src/libmd/: md5.copyright md5hl.c cm3/m3-tools/cvsup/suptcp/src/common/: SupTCP.i3 Log message: remove $Id$ From jkrell at elego.de Sun Mar 28 11:07:17 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:07:17 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328090717.258542474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:07:17 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: no need for an "object", just make everything global From jkrell at elego.de Sun Mar 28 11:10:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:10:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328091049.DDB102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:10:49 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: expand critical section in shutdown From jkrell at elego.de Sun Mar 28 11:31:00 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:31:00 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093100.CC7712474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:31:00 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 RTProcess.i3 RTProcessC.c m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 Log message: cvsup/pthread_atfork fixes From jkrell at elego.de Sun Mar 28 11:33:11 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 11:33:11 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328093313.0DA382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 11:33:11 Modified files: cm3/m3-tools/cvsup/suplib/src/: SigHandler.m3 Log message: fix to work with pthreads, or with user thread revision, where fork() doesn't leave all threads running From jkrell at elego.de Sun Mar 28 12:07:46 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:07:46 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100747.0C4422474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:07:46 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 m3core.h Log message: partial merge from head: add calling conventions From jkrell at elego.de Sun Mar 28 12:09:07 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:09:07 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328100907.E147B2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:09:07 Modified files: cm3/m3-libs/m3core/src/: Tag: release_branch_cm3_5_8 platforms.quake Log message: copy from head: add PPC64_DARWIN From jkrell at elego.de Sun Mar 28 12:13:41 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:13:41 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328101341.497F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:13:41 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.m3 Log message: copy from head: whitespace only From jkrell at elego.de Sun Mar 28 12:34:49 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:34:49 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103449.63A522474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:34:49 Modified files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcess.i3 m3makefile cm3/m3-libs/m3core/src/thread/POSIX/: Tag: release_branch_cm3_5_8 ThreadPosix.m3 cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Added files: cm3/m3-libs/m3core/src/runtime/common/: Tag: release_branch_cm3_5_8 RTProcessC.c Log message: merge cvsup/pthread_atfork changes from head to release From jkrell at elego.de Sun Mar 28 12:36:19 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:36:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103619.DF5F42474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:36:19 Modified files: cm3/m3-tools/cvsup/suplib/src/: Tag: release_branch_cm3_5_8 SigHandler.m3 Log message: copy from head for pthreads compatibility (fork() leaves just one thread, userthreads this way now too) From jkrell at elego.de Sun Mar 28 12:38:58 2010 From: jkrell at elego.de (Jay Krell) Date: Sun, 28 Mar 2010 12:38:58 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328103858.2C6222474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/28 12:38:58 Modified files: cm3/m3-libs/m3core/src/thread/PTHREAD/: Tag: release_branch_cm3_5_8 ThreadPThread.m3 Log message: fix From wagner at elego.de Sun Mar 28 15:07:02 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:07:02 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328130702.734C62474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:07:02 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: temporarily turn on command tracing From wagner at elego.de Sun Mar 28 15:33:24 2010 From: wagner at elego.de (Olaf Wagner) Date: Sun, 28 Mar 2010 15:33:24 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100328133324.CBC312474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 10/03/28 15:33:24 Modified files: cm3/scripts/regression/: Tag: release_branch_cm3_5_8 defs.sh Log message: disable command tracing again From jkrell at elego.de Mon Mar 29 20:47:55 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 20:47:55 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329184755.5D2D4CC37C@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 20:47:55 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: change Multiplier from a variable to a constant From jkrell at elego.de Mon Mar 29 21:05:16 2010 From: jkrell at elego.de (Jay Krell) Date: Mon, 29 Mar 2010 21:05:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329190516.7304F2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/29 21:05:16 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: make it clearer From hosking at elego.de Mon Mar 29 21:13:19 2010 From: hosking at elego.de (Antony Hosking) Date: Mon, 29 Mar 2010 21:13:19 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100329191319.BE5EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 10/03/29 21:13:19 Modified files: cm3/m3-libs/libm3/src/table/: Table.mg Log message: Cleaner code (don't obfuscate history). No need for initialization of fields when the initializer can do that. From jkrell at elego.de Tue Mar 30 11:46:52 2010 From: jkrell at elego.de (Jay Krell) Date: Tue, 30 Mar 2010 11:46:52 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100330094652.3FF612474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/30 11:46:52 Modified files: cm3/m3-libs/m3core/src/types/: m3makefile Log message: include Int64 on NT386 From jkrell at elego.de Wed Mar 31 15:17:27 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:17:27 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331131727.7D1E12474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:17:27 Modified files: cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 UnixC.c Log message: add Unix.tell, at least for Win32 and Solaris, real goal is to add minimal Unix on Win32, and then run libm3 tests From jkrell at elego.de Wed Mar 31 15:34:21 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:34:21 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133421.BBF382474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:34:21 Modified files: cm3/m3-libs/m3core/src/: m3core.h Log message: Unix__tell here too From jkrell at elego.de Wed Mar 31 15:35:43 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:35:43 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331133543.E90102474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:35:43 Modified files: cm3/m3-libs/m3core/src/unix/: m3makefile cm3/m3-libs/m3core/src/unix/Common/: Usocket.c m3makefile cm3/m3-libs/m3core/src/unix/WIN32/: m3makefile Added files: cm3/m3-libs/m3core/src/unix/WIN32/: Usysdep.i3 Removed files: cm3/m3-libs/m3core/src/unix/WIN32/: Unix.i3 Uuio.i3 Log message: greatly increase availability of src/unix on Win32, as much of it is actually provided by msvcr*dll From jkrell at elego.de Wed Mar 31 15:54:16 2010 From: jkrell at elego.de (Jay Krell) Date: Wed, 31 Mar 2010 15:54:16 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20100331135417.510EB2474003@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/03/31 15:54:16 Modified files: cm3/m3-libs/libm3/src/os/WIN32/: OSConfigWin32.m3 Log message: better fallbacks for InitUserName, InitUserHome