bison -d parser.ypp
flex -+ scanner.l
g++ -Wall -g -c -o variable.o variable.cc
In file included from variable.h:18,
from variable.cc:18:
type.h: In member function virtual bool t_struct::operator==(const type&) const:
type.h:179: error: strcmp was not declared in this scope
type.h: In member function virtual const t_struct::field* t_struct::get_field(const char*) const:
type.h:200: error: strcmp was not declared in this scope
In file included from variable.cc:22:
compiler.h: In member function void compiler::set_effective_location(const char*, int):
compiler.h:96: error: strdup was not declared in this scope
make: *** [variable.o] Ошибка 1
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)
Shaos wrote:
... 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)
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.
eudoxie wrote:
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.
OK, and I'll check current code under MacOS X 10.4 on my PowerBook G4
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.
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).
Shaos wrote:
OK, and I'll check current code under MacOS X 10.4 on my PowerBook G4
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...
