I looked at Kevin Kofler's documentation from the TIGCC website... and a lot of it really doesn't make sense. What I'm wondering is this: Is there a routine that one can call, sort of like the Sprite8,Sprite16, and Sprite32 functions, that takes a grayscale sprite and draws it? What do I need to do in my program to set up the grayscale buffers? How would I encode a grayscale sprite?
Quote:
I looked at Kevin Kofler's documentation from the TIGCC website
Newer documentation is available from https://debrouxl.github.io/gcc4ti/ .
FWIW, GCC4TI provides and normally documents sprite functions which are both faster and smaller than the dead ancestor's versions, despite supporting one additional drawing mode. This is one of the many contributions to the dead ancestor which were at best never merged for no good reason, or at worst rejected for outright improper reasons ("serves no purpose", despite multiple persons needing to use the contributed functionality over the years...).
Quote:
Is there a routine that one can call, sort of like the Sprite8,Sprite16, and Sprite32 functions, that takes a grayscale sprite and draws it?
For the simple drawing modes, multiple calls to the single plane sprite routine do the job. For the advanced drawing modes (transparency, etc.), you need other routines.
Quote:
What do I need to do in my program to set up the grayscale buffers?
There are multiple grayscale-related examples in GCC4TI and its dead ancestor. Also, among others, you can have a look at a variety of TICT programs: Thomas Nussbaumer made them open source, they're reasonably well commented and some of them are simple.
At some point, in GCC4TI, I made sure that not only all of the examples could be built, but also, that their on-calc names do not clash with each other.
Quote:
How would I encode a grayscale sprite?
That's conventional, there exist multiple formats for grayscale sprites. Some routines expect (full data for one plane followed by full data for the other plane), others expect it the other way around, others take two different arguments for the light plane and the dark plane (which has the upside of allowing some sharing of light or dark plane data), others expect interlaced sprite data. And then there's masking data, when using that
There are basically two modern graphics libraries for TI-68k/AMS:
* ExtGraph, compile-time library from TICT, to which I added lots of routines (and bugs, though I fixed the known ones ^^). There are 30+ demo programs, many of which use grayscale routines;
* genlib, run-time library which requires users to install PreOS. Fewer, more focused functions; much less popular than ExtGraph. That does absolutely not mean it's bad, in fact ExtGraph took a number of clues from genlib, but requiring PreOS isn't universally considered a good thing for usability
At my suggestion, ExtGraph was also used as a source of inspiration for the TI-eZ80 graphics libraries, AFAIK.
BTW: don't hesitate to ping me more directly if you post other TI-68k-related topics and I don't see them quickly. I happened to notice this one on #cemetech, but sometimes I miss them.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Thank you! I looked at the documentation you suggested and a couple demos, but I still couldn't get grayscale to work fully. I realized that I need to call GranOn to turn grayscale on and GrayOff before exiting, and I'm substituting GrayGetPlane for LCD_MEM... but I only managed to get 2 grayscale levels.
I can't figure out why, but using GrayGetPlane(0) draws light gray (in Sprite8) and passing any other value causes it to draw with full strength. Is there something I forgot to do?
I can't figure out why, but using GrayGetPlane(0) draws light gray (in Sprite8) and passing any other value causes it to draw with full strength. Is there something I forgot to do?
* do the demos in the GCC4TI distribution work unmodified ? Fresh builds of both do for me, on two different emulators;
* check your contrast settings;
* which emulator are you using, and while at it, which calculator model and hardware revision ?
* which version of GCC4TI are you using ?
* are you using idle() in your program ? That won't work when using grayscale.
* check your contrast settings;
* which emulator are you using, and while at it, which calculator model and hardware revision ?
* which version of GCC4TI are you using ?
* are you using idle() in your program ? That won't work when using grayscale.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Actually, I'm using GTC right now on a physical calculator while I try to remove the ancient version of TIGCC I had installed. I have tiemu installed, and its working.
GCC4TI is giving me some problems, because the installation script can't find binutils.
Here is the system information:
Computer: OSX Yosemite
Calculator: HW4, AMS 3.10
Contrast settings don't change anything, and I haven't typed in the source code for the demos yet, only looked at the source code.
GCC4TI is giving me some problems, because the installation script can't find binutils.
Here is the system information:
Computer: OSX Yosemite
Calculator: HW4, AMS 3.10
Contrast settings don't change anything, and I haven't typed in the source code for the demos yet, only looked at the source code.
Quote:
GCC4TI is giving me some problems, because the installation script can't find binutils.
Heh. GCC4TI's build scripts normally work much better than the dead ancestor's, especially for non-Linux ^^
Did you build from the Git repo (in my signature) ? The default "next" branch is good, and if you want to go further, the "experimental" branch contains size+speed optimizations on the grayscale routines.
Quote:
Actually, I'm using GTC right now on a physical calculator
Judging by the dates, GTC's library ought to support the 89T, but improper operation of grayscale could be a sign that it doesn't.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Here's what I did:
Clone the repo using git
cd trunk/tigcc-linux/scripts
./Install
I have the tarball with binutils in it; where do I put the tarball? Or should I extract the stuff first? I actually have binutils installed already, but the binaries are sitting in /usr/local/Cellar/binutils/ and they aren't symlinked to /usr/local.
This actually isn't as bad as tigcc. At least I get error messages instead of some non-working executables.
Clone the repo using git
cd trunk/tigcc-linux/scripts
./Install
I have the tarball with binutils in it; where do I put the tarball? Or should I extract the stuff first? I actually have binutils installed already, but the binaries are sitting in /usr/local/Cellar/binutils/ and they aren't symlinked to /usr/local.
This actually isn't as bad as tigcc. At least I get error messages instead of some non-working executables.
Quote:
Here's what I did:
Clone the repo using git
cd trunk/tigcc-linux/scripts
./Install
Clone the repo using git
cd trunk/tigcc-linux/scripts
./Install
Well, the README down the main Github page for the repo indicates that you need to run updatesrc and run the install script from the just built source tree
Quote:
I have the tarball with binutils in it; where do I put the tarball? Or should I extract the stuff first?
updatesrc takes care of it.
Quote:
At least I get error messages instead of some non-working executables.
Right, that's one of the improvements we made to the inherited build scripts, besides portability and general reliability. Silently producing broken builds isn't acceptable for just any sane build system...
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Well, I figured out some more things:
1) I did run updatesrc, but I was in the wrong directory. I ran scripts/updatesrc instead of cd scripts and updatesrc. That's why it failed. Now, it gets all the way through until here:
...
-n .
-n .
.
Updating scripts...
chmod: ../gcc4ti-0.96b11/scripts/[^S]*: Not a directory
Creating symlinks...
Done.
Then, the install script is missing. If I copy the scripts over from linux-tigcc/scripts and run them, it starts a long compilation and ends with a couple thousand errors.
I'm not using linux and I'm following the linux instructions, so would that matter?
1) I did run updatesrc, but I was in the wrong directory. I ran scripts/updatesrc instead of cd scripts and updatesrc. That's why it failed. Now, it gets all the way through until here:
...
-n .
-n .
.
Updating scripts...
chmod: ../gcc4ti-0.96b11/scripts/[^S]*: Not a directory
Creating symlinks...
Done.
Then, the install script is missing. If I copy the scripts over from linux-tigcc/scripts and run them, it starts a long compilation and ends with a couple thousand errors.
I'm not using linux and I'm following the linux instructions, so would that matter?
Quote:
I'm not using linux and I'm following the linux instructions, so would that matter?
That should not. At the time, we definitely made sure that the build scripts worked on MacOS X - the scripts contain various workarounds for MacOS X peculiarities, so that unlike the dead ancestor, GCC4TI could be successfully installed on MacOS X without lots of user hand-holding - but that was over a decade ago
Still, maybe the build scripts need a few adjustments I wasn't aware of.
You're not telling me what those errors are, so I'm left to guessing what might be occurring
One source of errors that I can think of is the usage of Clang; while that is a good compiler in general, which provides good compatibility with GCC, such outdated versions of GCC use GCC-specific extensions and can only be built by GCC.
I fixed the code of ld-tigcc not to depend on non-portable GCC extensions such as nested functions, but getting a 15-year-old GCC version to build without GCC is a whole other matter...
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Several thousand occurrences of "Warning: -s option is deprecated" and Warning: unused compiler option "-s", then some weird fatal errors with hundred line long stacktraces.
Also: another question:
Which one is better, GCC4TI, or TIGCC? The TIGCC website says TIGCC (which you call the "dead ancestor" or GCC4TI) is NOT dead, and the GCC4TI is a lower quality version. I'm kind of skeptical, because the last activity on GCC4TI was around a year ago and TIGCC hasn't been touched in 6-7 years.
Also: another question:
Which one is better, GCC4TI, or TIGCC? The TIGCC website says TIGCC (which you call the "dead ancestor" or GCC4TI) is NOT dead, and the GCC4TI is a lower quality version. I'm kind of skeptical, because the last activity on GCC4TI was around a year ago and TIGCC hasn't been touched in 6-7 years.
- Lionel Debroux
- Minor Calculator Deity (Posts: 1324)
- 22 Sep 2020 10:27:39 am
- Last edited by Lionel Debroux on 22 Sep 2020 03:06:27 pm; edited 2 times in total
Quote:
then some weird fatal errors with hundred line long stacktraces.
Alright, but which ones ?
Also, what does
Code:
gcc --version
return on your build environment ?
Quote:
Which one is better, GCC4TI, or TIGCC?
Well, you're asking me, one of the creators and by far the main contributor to GCC4TI (after being a former contributor to the dead ancestor and being listed in the credits for my contributions)
Quote:
The TIGCC website says TIGCC (which you call the "dead ancestor" of GCC4TI) is NOT dead, and the GCC4TI is a lower quality version. I'm kind of skeptical, because the last activity on GCC4TI was around a year ago and TIGCC hasn't been touched in 6-7 years.
Freedom of speech makes the dead ancestor's maintainer free to pretend whatever he wants, and even try to convince others about anything
On my side, I'll just look at some relevant facts:
* you've correctly found which project has seen the largest amount of work and the most recent work, though there's not been that much work since 2012, but the ancestor is worse in that respect;
* in this topic, you've already read about multiple useful changes performed on the GCC4TI side.
I'll now give a very high-level overview of the effect of the changes performed on the GCC4TI side:
* better usability: build scripts !, VTI support even though that's not really advised, etc. - and of course, on the developer side, switching from the awful CVS to a usable VCS, at first SVN, then Git like nearly everybody else;
* better reliability: build scripts !, or merely making the source control tree complete: on the dead ancestor, some files are available only in some release tarballs, they're missing from the CVS repository;
* better portability: code, build scripts !!
* more features: new functions, etc. - but also the integration of the TI-68k Developer Utilities, a TICT project which Thomas Nussbaumer always meant to be partially integrated to the development environment, and which, nearly two decades after its creation, still serves as a source of inspiration - and relatively high priority todo/wish list item for a CLI front-end to libti* ( https://github.com/debrouxl/tilibs/issues/31 );
* more optimizations: some code bits very commonly duplicated across AMS native programs were optimized on the GCC4TI side, e.g. SAVE_SCREEN, _rowread, the Sprite* functions; qsort() is quite a bit faster despite being smaller; etc.
* fewer bugs: last time I checked, even my fixes on the GCC4TI side for calculator-crashing bugs reported on the dead ancestor's side after the creation of GCC4TI did not get integrated into the dead ancestor. In addition to this, for instance, GCC4TI has a bsearch() routine whose algorithm actually works (and is smaller, too).
* better documentation: for instance, there's a configuration sample for the documentation generator tools. Fortunately, I had a working config file since my earlier attempts at contributing more to the dead ancestor...
The full details are in the GCC4TI commit history, you or anybody else can technically check for yourself my statements anyway, and can make your own opinion about both sides' statements and underlying motivations
Is GCC4TI perfect ? Well, nothing is.
Is it, on average, in better shape than the dead ancestor ? Definitely, for multiple reasons I outlined. We performed software engineering on it, which makes it more usable over a decade later.
Could we have done better ? Definitely, by spending much more time on it. However, I spent much more time on libti*/gfm/tilp, because those had - and still have - far more users, so that's where spending time makes the most sense. Even if for a while, I clearly had more fun on the GCC4TI side.
Some changes we did intentionally not make on the GCC4TI side include pursuing the folly of imposing a KDE-based IDE on all platforms (without fixing the Delphi IDE's well-identified defects, at that). More than 11 years after the announcement of this plan - after a number of other events - triggered the creation of GCC4TI, as we correctly predicted:
* not only KDE remains basically nonexistent in the non-Linux world, which happens to include the Windows and macOS giants, but...
* 1) the severe instability of KDE 4 and KDE 4-based programs during the two first years of its life cycle cost extremely dearly to the market share of KDE even on Linux. API breakage over the KDE 4.x series, some of which hit that KDE-based IDE, made KDE 4.x even harder to support. In terms of popularity, KDE never recovered, even with '2020 KDE 5.x, despite its general level of features and polish... And with Qt 6 on the horizon, I guess that there will be a KDE 6.x series, so more breakage at first.
* 2) in the meantime, FreePascal and Lazarus improved in terms of reliability, portability and compatibility with Delphi, so the maintenance and evolution of Delphi-based code from a Linux enviroment is easier than it used to be.
Ah, forgot to mention: the code quality and maintainability of the KDE-based IDE are terrible. Like the my other statements, this one can easily be checked by looking at the code: multiple huge and poorly commented files, to begin with.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
gcc --version (which is clang --version) gives:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
And the errors are the generic Apple clang stuff:
Code:
EDIT:
Later on, more errors appear.
Code:
I think it's because of clang. Should I remove the symlink to gcc and actually install it?
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
And the errors are the generic Apple clang stuff:
Code:
Undefined symbols for architecture x86_64:
"_bfd_abs_section", referenced from:
_sysv_internal_sizer in size.o
_sysv_internal_printer in size.o
"_bfd_arch_list", referenced from:
_list_supported_architectures in bucomm.o
"_bfd_check_format", referenced from:
_display_file in size.o
_display_bfd in size.o
"_bfd_check_format_matches", referenced from:
_display_bfd in size.o
"_bfd_close", referenced from:
_display_file in size.o
"_bfd_close_all_done", referenced from:
_display_info in bucomm.o
"_bfd_core_file_failing_command", referenced from:
_display_bfd in size.o
"_bfd_errmsg", referenced from:
_bfd_nonfatal in bucomm.o
_set_default_bfd_target in bucomm.o
"_bfd_get_error", referenced from:
_display_file in size.o
_display_bfd in size.o
_bfd_nonfatal in bucomm.o
_set_default_bfd_target in bucomm.o
_display_info in bucomm.o
"_bfd_init", referenced from:
_main in size.o
"_bfd_map_over_sections", referenced from:
_print_sizes in size.o
"_bfd_openr", referenced from:
_display_file in size.o
"_bfd_openr_next_archived_file", referenced from:
_display_file in size.o
"_bfd_openw", referenced from:
_display_info in bucomm.o
"_bfd_printable_arch_mach", referenced from:
_display_info in bucomm.o
"_bfd_scan_vma", referenced from:
_parse_vma in bucomm.o
"_bfd_set_default_target", referenced from:
_set_default_bfd_target in bucomm.o
"_bfd_set_error", referenced from:
_display_file in size.o
"_bfd_set_format", referenced from:
_display_info in bucomm.o
"_bfd_target_list", referenced from:
_list_supported_targets in bucomm.o
"_bfd_target_vector", referenced from:
_display_info in bucomm.o
"_bfd_und_section", referenced from:
_sysv_internal_sizer in size.o
_sysv_internal_printer in size.o
"_make_temp_file", referenced from:
_display_info in bucomm.o
"_xexit", referenced from:
_bfd_fatal in bucomm.o
_fatal in bucomm.o
"_xmalloc", referenced from:
_make_tempname in bucomm.o
"_xmalloc_set_program_name", referenced from:
_main in size.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: [size] Error 1 (ignored)
gcc -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DHAVE_CONFIG_H -I. -I../../../download/binutils.ti/binutils -I. -D_GNU_SOURCE -I. -I../../../download/binutils.ti/binutils -I../bfd -I../../../download/binutils.ti/binutils/../bfd -I../../../download/binutils.ti/binutils/../include -I../../../download/binutils.ti/binutils/../intl -I../intl -DLOCALEDIR="\"/usr/local/share/gcc4ti/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Os -s -fno-exceptions -fomit-frame-pointer -c ../../../download/binutils.ti/binutils/objdump.c
clang: warning: argument unused during compilation: '-s'
gcc -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DHAVE_CONFIG_H -I. -I../../../download/binutils.ti/binutils -I. -D_GNU_SOURCE -I. -I../../../download/binutils.ti/binutils -I../bfd -I../../../download/binutils.ti/binutils/../bfd -I../../../download/b
EDIT:
Later on, more errors appear.
Code:
../../../download/gcc.ti/gcc/machmode.h:125:13: note: forward
declaration of 'enum machine_mode'
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
5 warnings and 20 errors generated.
make[2]: [tree-tailcall.o] Error 1 (ignored)
gcc -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -c -Os -s -fno-exceptions -fomit-frame-pointer -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../../download/gcc.ti/gcc -I../../../download/gcc.ti/gcc/. -I../../../download/gcc.ti/gcc/../include -I../../../download/gcc.ti/gcc/../libcpp/include ../../../download/gcc.ti/gcc/gimple-low.c -o gimple-low.o
clang: warning: argument unused during compilation: '-s'
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
In file included from ../../../download/gcc.ti/gcc/tree.h:25:
../../../download/gcc.ti/gcc/machmode.h:30:37: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const char * const mode_name[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:44:39: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_class[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:81:8: error: unknown type name
'CONST_MODE_SIZE'
extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:81:24: error: expected
identifier or '('
extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:86:44: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned short mode_precision[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:92:53: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned HOST_WIDE_INT mode_mask_array[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:98:39: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_inner[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:110:40: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_nunits[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:115:39: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_wider[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:118:41: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:125:13: warning: ISO C forbids
forward references to 'enum' types [-Wpedantic]
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
../../../download/gcc.ti/gcc/machmode.h:145:8: error: unknown type name
'CONST_MODE_BASE_ALIGN'
extern CONST_MODE_BASE_ALIGN unsigned char mode_base_align[NUM_...
^
../../../download/gcc.ti/gcc/machmode.h:145:30: error: expected
identifier or '('
extern CONST_MODE_BASE_ALIGN unsigned char mode_base_align[NUM_...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:202:9: error: use of undeclared
identifier 'MAX_MODE_COMPLEX_FLOAT'; did you mean
'MODE_COMPLEX_FLOAT'?
+ MAX_MODE_COMPLEX_FLOAT
^~~~~~~~~~~~~~~~~~~~~~
MODE_COMPLEX_FLOAT
../../../download/gcc.ti/gcc/machmode.h:37:19: note:
'MODE_COMPLEX_FLOAT' declared here
enum mode_class { MODE_CLASSES, MAX_MODE_CLASS };
^
../../../download/gcc.ti/gcc/mode-classes.def:29:19: note: expanded
from macro 'MODE_CLASSES'
DEF_MODE_CLASS (MODE_COMPLEX_FLOAT)...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:203:9: error: use of undeclared
identifier 'MIN_MODE_COMPLEX_FLOAT'; did you mean
'MODE_COMPLEX_FLOAT'?
- MIN_MODE_COMPLEX_FLOAT,
^~~~~~~~~~~~~~~~~~~~~~
MODE_COMPLEX_FLOAT
../../../download/gcc.ti/gcc/machmode.h:37:19: note:
'MODE_COMPLEX_FLOAT' declared here
enum mode_class { MODE_CLASSES, MAX_MODE_CLASS };
^
../../../download/gcc.ti/gcc/mode-classes.def:29:19: note: expanded
from macro 'MODE_CLASSES'
DEF_MODE_CLASS (MODE_COMPLEX_FLOAT)...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:208:9: error: use of undeclared
identifier 'MAX_MODE_COMPLEX_FLOAT'; did you mean
'MODE_COMPLEX_FLOAT'?
+ MAX_MODE_COMPLEX_FLOAT
^~~~~~~~~~~~~~~~~~~~~~
MODE_COMPLEX_FLOAT
../../../download/gcc.ti/gcc/machmode.h:37:19: note:
'MODE_COMPLEX_FLOAT' declared here
enum mode_class { MODE_CLASSES, MAX_MODE_CLASS };
^
../../../download/gcc.ti/gcc/mode-classes.def:29:19: note: expanded
from macro 'MODE_CLASSES'
DEF_MODE_CLASS (MODE_COMPLEX_FLOAT)...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:209:9: error: use of undeclared
identifier 'MIN_MODE_COMPLEX_FLOAT'; did you mean
'MODE_COMPLEX_FLOAT'?
- MIN_MODE_COMPLEX_FLOAT,
^~~~~~~~~~~~~~~~~~~~~~
MODE_COMPLEX_FLOAT
../../../download/gcc.ti/gcc/machmode.h:37:19: note:
'MODE_COMPLEX_FLOAT' declared here
enum mode_class { MODE_CLASSES, MAX_MODE_CLASS };
^
../../../download/gcc.ti/gcc/mode-classes.def:29:19: note: expanded
from macro 'MODE_CLASSES'
DEF_MODE_CLASS (MODE_COMPLEX_FLOAT)...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:1245:1: warning: using extended
field designator is an extension [-Wextended-offsetof]
DEF_VEC_ALLOC_O(constructor_elt,gc);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../download/gcc.ti/gcc/vec.h:756:32: note: expanded from macro
'DEF_VEC_ALLOC_O'
...\
^
../../../download/gcc.ti/gcc/vec.h:927:44: note: expanded from macro '\
DEF_VEC_ALLOC_FUNC_O'
...offsetof (VEC(T,A),base.vec), \
^ ~~~~
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/include/stddef.h:120:24: note:
expanded from macro 'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
^ ~
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:1245:1: warning: using extended
field designator is an extension [-Wextended-offsetof]
DEF_VEC_ALLOC_O(constructor_elt,gc);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../download/gcc.ti/gcc/vec.h:756:32: note: expanded from macro
'DEF_VEC_ALLOC_O'
...\
^
../../../download/gcc.ti/gcc/vec.h:942:5: note: expanded from macro '\
DEF_VEC_ALLOC_FUNC_O'
offsetof (VEC(T,A),base.vec), s...
^ ~~~~
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/include/stddef.h:120:24: note:
expanded from macro 'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
^ ~
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:1245:1: warning: using extended
field designator is an extension [-Wextended-offsetof]
DEF_VEC_ALLOC_O(constructor_elt,gc);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../download/gcc.ti/gcc/vec.h:756:32: note: expanded from macro
'DEF_VEC_ALLOC_O'
...\
^
../../../download/gcc.ti/gcc/vec.h:968:15: note: expanded from macro '\
DEF_VEC_ALLOC_FUNC_O'
...offsetof (VEC(T,A),base.vec),\
^ ~~~~
/Library/Developer/CommandLineTools/usr/bin/../lib/clang/8.0.0/include/stddef.h:120:24: note:
expanded from macro 'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
^ ~
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:1811:31: error: field has
incomplete type 'enum machine_mode'
ENUM_BITFIELD(machine_mode) mode : 7;
^
../../../download/gcc.ti/gcc/machmode.h:125:13: note: forward
declaration of 'enum machine_mode'
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:26:
../../../download/gcc.ti/gcc/tree.h:2188:31: error: field has
incomplete type 'enum machine_mode'
ENUM_BITFIELD(machine_mode) mode : 8;
^
../../../download/gcc.ti/gcc/machmode.h:125:13: note: forward
declaration of 'enum machine_mode'
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:27:
In file included from ../../../download/gcc.ti/gcc/rtl.h:28:
../../../download/gcc.ti/gcc/real.h:29:17: warning: attribute 'packed'
is ignored, place it after "struct" to apply attribute to type
declaration [-Wignored-attributes]
__attribute__ ((packed))
^
In file included from ../../../download/gcc.ti/gcc/gimple-low.c:27:
../../../download/gcc.ti/gcc/rtl.h:166:21: error: field has incomplete
type 'enum machine_mode'
enum machine_mode rt_type;
^
../../../download/gcc.ti/gcc/machmode.h:125:13: note: forward
declaration of 'enum machine_mode'
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
5 warnings and 20 errors generated.
make[2]: [gimple-low.o] Error 1 (ignored)
gcc -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -c -Os -s -fno-exceptions -fomit-frame-pointer -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../../download/gcc.ti/gcc -I../../../download/gcc.ti/gcc/. -I../../../download/gcc.ti/gcc/../include -I../../../download/gcc.ti/gcc/../libcpp/include ../../../download/gcc.ti/gcc/tree-iterator.c -o tree-iterator.o
clang: warning: argument unused during compilation: '-s'
In file included from ../../../download/gcc.ti/gcc/tree-iterator.c:25:
In file included from ../../../download/gcc.ti/gcc/tree.h:25:
../../../download/gcc.ti/gcc/machmode.h:30:37: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const char * const mode_name[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:44:39: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_class[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:81:8: error: unknown type name
'CONST_MODE_SIZE'
extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:81:24: error: expected
identifier or '('
extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:86:44: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned short mode_precision[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:92:53: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned HOST_WIDE_INT mode_mask_array[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:98:39: error: use of undeclared
identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_inner[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:110:40: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_nunits[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:115:39: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_wider[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:118:41: error: use of
undeclared identifier 'NUM_MACHINE_MODES'
extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
^
../../../download/gcc.ti/gcc/machmode.h:125:13: warning: ISO C forbids
forward references to 'enum' types [-Wpedantic]
extern enum machine_mode mode_for_size (unsigned int, enum mode...
^
../../../download/gcc.ti/gcc/machmode.h:145:8: error: unknown type name
'CONST_MODE_BASE_ALIGN'
I think it's because of clang. Should I remove the symlink to gcc and actually install it?
Yes, you'll need to use GCC to build the ancient GCC 4.1.2 & binutils 2.16... and probably an older version of GCC, even: GCC 4.9 from the Debian Jessie timeframe and 5.x are supposed to be decent enough for a Linux environment, but a GCC 4.9 cross-compiler targeting Windows is known to produce a broken compiler (for floating-point values, at least), and I haven't tested the build on recent GCC versions...
Temporarily changing the gcc symlink will do the job, but that shouldn't be necessary if you enter the name of another executable (which should probably be in your PATH, though I'd expect a full file path to work as well) at the beginning of the invocation of the Install script.
Temporarily changing the gcc symlink will do the job, but that shouldn't be necessary if you enter the name of another executable (which should probably be in your PATH, though I'd expect a full file path to work as well) at the beginning of the invocation of the Install script.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Well, I was unable to get gcc to install. 4.9 isn't even available anymore except in source format, and it refuses to build with Apple's clang.
On the bright side, I figured out the graysacle thing:
Light gray: Draw the sprite to the LIGHT_PLANE
Med gray: Draw the sprite to the DARK_PLANE
Dark gray: Draw the sprite to both planes
Thank you for all your assistance!
On the bright side, I figured out the graysacle thing:
Light gray: Draw the sprite to the LIGHT_PLANE
Med gray: Draw the sprite to the DARK_PLANE
Dark gray: Draw the sprite to both planes
Thank you for all your assistance!
ExtGraph's sprite routines do that for you, but since you don't have a working build of GCC4TI yet, ExtGraph won't help you right now...
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Well, I wrote a sprite routine. It takes a 2D array of chars that gives the gray level. 0 is transparent. passing 1 for cache means skip recalculation of the panes and just draw it. The code works, but it's slow and I really need to optimize it. I wish I could get GCC4TI to work...
Code:
Code:
void GraySpr16(short x, short y, unsigned char spr[16][16],char cached){
static unsigned short imask[16],buff1[16],buff2[16],i,j;
if(cached)goto DRAW;
for(i=0;i<16;i++){
for(j=0;j<16;j++){
if(spr[i][j]==0){
imask[i]++;
}
if(spr[i][j]==2||spr[i][j]>=4){
buff1[i]++;
}
if(spr[i][j]>=3){
buff2[i]++;
}
imask[i]<<=1;
buff1[i]<<=1;
buff2[i]<<=1;
}
}
DRAW:;
Sprite16(x,y,16,imask,GrayGetPlane(LIGHT_PLANE),SPRT_AND);
Sprite16(x,y,16,imask,GrayGetPlane(DARK_PLANE),SPRT_AND);
Sprite16(x,y,16,buff1,GrayGetPlane(LIGHT_PLANE),SPRT_OR);
Sprite16(x,y,16,buff2,GrayGetPlane(DARK_PLANE),SPRT_OR);
}
I don't have access to a MacOS X computer I could use interactively for testing purposes, I'll have to get that somehow (or have someone else try things for me while we communicate through IRC)
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
I have tested some things and gave the log to debrouxl for further analysis, hopefully we can fix a few things in the code and build scripts to make it work more smoothly.
Adriweb's log of a build using GCC 10 shows the same build errors as in https://github.com/debrouxl/gcc4ti/issues/13 .
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page 1, 2 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 1 of 2
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement