Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
1st run on G4-Cube with Debian 5.0:
This is for gcc (Debian 4.3.2-1.1) 4.3.2
|
21 Aug 2009 19:15 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
after minor fixes in tryte.cc (order of initialization in constructor) and machine.h (#include <string.h> for strdup):
|
21 Aug 2009 19:27 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
after aptitude install flex tunguska and tg_assembler were compiled successfully
after installing packages for GTK development:
P.S. Also I fixed Makefile to avoid constant recompilation of lex.yy.o and parser.tab.o
|
21 Aug 2009 19:54 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
tunguska_3cc also requires #include <string.h>
fixed type.h and Makefile (for lex and parser rules)
P.S. Everything is working now on my G4 Cube (Initial benchmark: 177.722 thousand operations per second), but tg_assembler produces different file than little-endian machine and I can fix it (to produce little-endian output file even on big-endian machines and to parse it as little-endian in Tunguska)
|
21 Aug 2009 22:08 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
memory.cc is fixed and now tg_assembler always produces little-endian output even on big-endian machines and tunguska on big-endian successfully reads input files created on little-endian machines.
|
22 Aug 2009 15:03 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
So it's time to release 0.5.1?
|
25 Aug 2009 18:34 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
I've got a few small things to fix, but otherwise, sure. It's got enough fixes to merit a release. I'll try to have a test package ready this weekend.
|
25 Aug 2009 18:44 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
OK, and I'll check current code under MacOS X 10.4 on my PowerBook G4
|
25 Aug 2009 19:29 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
Fixed the embarrassing error in symbols.bmp.
Compiles and runs fine on gentoo x86_64 now with your fixes
|
28 Aug 2009 18:52 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
That's great!
I do not have 64-bit Linux yet...
|
28 Aug 2009 19:04 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
I've been thinking, it wouldn't be that much work to have AGDP make use of gcc's OpenMP support to allow parallelization of block transfer operations. They're pragma instructions, so they're fully backwards compatible with non-OpenMP ready compilers, and should seriously reduce the speed the block transfer operations take on multicore CPUs.
Preliminary testing shows that OpenMP-enabled for loops boosts the benchmark on the assembly memory image from ~1500 kOP/s to ~1600 kOP/s on my dual core CPU. Which is a really cheap speed boost, seeing as how the code is only modified at half a dozen places to make it work.
|
29 Aug 2009 11:45 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
May be to fully utilize 2-core machine the better strategy is using 2 threads: 1st for graphics and 2nd for calculation itself?
|
29 Aug 2009 21:25 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
That was easier to do before when memory registers weren't asynchronous like they are now, since SDL isn't thread safe making it necessary to do both input and output in the same thread.
A better approach to reduce the graphics overhead is to add some sort minimum redraw interval. Right now, the code often calls updates of the screen way too often (making, worst case scenario, 30% of the CPU time being spent doing nothing but updating the screen).
|
30 Aug 2009 10:31 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
Actually, I tested that approach, and the initial results aren't looking promising. But I think I have a few ideas on ways it might be made to work.
|
30 Aug 2009 10:44 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22743 Location: Silicon Valley
|
I checked - bad news
MacOS X 10.4 has older bison version 1.28 that doesn't create cpp/hpp, instead it creates c/h files and I can't compile it even after renaming...
|
04 Sep 2009 21:41 |
|
|