2024-01-31 20:14:01 hi, i got rather deep in a project to compile pforth on an old, but POSIX compatible, QNX4 system (running on a 32-bit PC-compatible). The latest thing I'm getting hung up on is that pforth is supposed to be portable to systems that support 32 bit integers and pointers, but the pforth code uses uint64_t in a number of places. 2024-01-31 20:14:32 what does it mean to use a uint64 data type on a 32 bit platform 2024-01-31 20:15:52 is uint64_t supposed to be undefined on 32 bit platforms, or is there some trick to get a fake 64 bit data type? 2024-01-31 20:16:42 strictly speaking, if you use uint64_t you automatically forgo any right to call your code portable 2024-01-31 20:16:59 You can do 64 bit operations on any size of machine, it just may take more operations 2024-01-31 20:17:17 yes, but the C standard allows for uint64_t to be undefined 2024-01-31 20:18:07 uint_least64_t and uint_fast64_t are the portable typedefs 2024-01-31 20:19:11 so, I suppose, newer compilers must know how to handle uint64_t operations on platforms that don't have real 64 bit registers? 2024-01-31 20:19:34 they may, but they're not required to by the standard 2024-01-31 20:19:43 No, zelgomer is right, uint64_t only exists if the hardware actually suppports 2024-01-31 20:19:58 "provided only if the implementation directly supports the type" https://en.cppreference.com/w/c/types/integer 2024-01-31 20:20:23 Hmmm ... actually it says implementation, I suppose it could still be there as long as the compiler will generate te code 2024-01-31 20:20:42 hmm, so to get this to work, with this old compiler, it sounds like I'll need to adjust the pforth code to not use uint64_t 2024-01-31 20:21:06 or define uint64_t your self 2024-01-31 20:21:25 define it to be the same as unit32_t or something? 2024-01-31 20:21:34 uint32_t, I meant 2024-01-31 20:21:44 what does this compiler generate for unsigned long long? 2024-01-31 20:22:05 printf("%zu\n", sizeof (unsigned long long)); 2024-01-31 20:23:16 and how old is this compiler? does it have stdint.h? 2024-01-31 20:23:59 it is a 20 year old version of WATCOM. It does not have a stdint.h. Someone here suggested I try pstdint.h from the Internet, so am trying to make that work 2024-01-31 20:26:03 Fixed width integers are from C99, if it's 20 years old it might still have them :P 2024-01-31 20:26:20 most of pstdint.h seems to be working but compiler chokes when it finds uint64_t in pforth code. I think maybe I could tweak pstdint.h to get it to define that but am trying to wrap my head around what it is I am doing first 2024-01-31 20:27:19 I think this version of WATCOM was from just before C99 2024-01-31 20:28:03 the system is 20 years old, but compiler older 2024-01-31 20:28:04 c99 took a while to be adopted 2024-01-31 21:02:23 I figured out that pforth, apparently, only uses that unit64_t stuff in some code for a word to resize files, so I just commented that out 2024-01-31 21:02:38 hopefully I'll never need to resize a file 2024-01-31 21:06:38 hmm, now it is trying to include sys/poll.h, but watcom c library doesn't have that 2024-01-31 21:06:49 might be fighting a losing battle here 2024-01-31 21:08:25 when did poll.h get invented? 2024-01-31 21:09:21 "A poll() system call appeared in AT&T System V Release 3 UNIX." 2024-01-31 21:09:34 (but that might be a guess) 2024-01-31 21:09:48 when was that? 2024-01-31 21:10:41 1987, per wikipedia 2024-01-31 21:11:07 is poll.h different from sys/poll.h? 2024-01-31 21:11:35 poll.h on OpenBSD is a wafer thin include for sys/poll.h 2024-01-31 21:11:54 same on linux 2024-01-31 21:12:04 or debian, anyway 2024-01-31 21:12:47 don't seem to have either on this system 2024-01-31 21:13:05 maybe they put it in some other header file 2024-01-31 21:21:53 hmm, looks like QNX4 used select() from sys/select.h instead of poll() 2024-01-31 21:22:28 select is probably even older (4.1cBSD) 2024-01-31 21:23:00 but pforth has some defines for using select instead 2024-01-31 21:23:22 for MacOS Tiger 2024-01-31 21:25:27 abstractions like libevent will try to use the best one available 2024-01-31 21:30:53 ack, it is missing some of the termios local mode macros! 2024-01-31 21:31:00 ECHOCTL 2024-01-31 21:31:22 hmm, seems to be a BSD extension 2024-01-31 21:31:39 jerks 2024-01-31 21:32:16 maybe I can comment that out or something 2024-01-31 21:34:16 okay, I think I can just adjust it not to set that bit 2024-01-31 21:34:26 and see what chaos ensues 2024-01-31 21:41:21 okay, that compiles, heh heh 2024-01-31 21:41:49 that file, at least 2024-01-31 21:43:27 hmm, rats. No usleep 2024-01-31 21:45:34 also wants to use round from libm but no libm 2024-01-31 21:49:20 at some point you might be better off writing your own forth 2024-01-31 21:49:22 I think these are both contained enough to be isolated out 2024-01-31 21:50:13 well, time wise, it would make more sense to just add a bunch of includes to pforth 2024-01-31 21:50:28 and reimplement a few things 2024-01-31 21:51:24 so forth, the missing stuff is all contained to a few non-essential forth words 2024-01-31 21:51:42 like resizing files, rounding floating points numbers, that sort of thing 2024-01-31 21:52:53 so far, I meant 2024-01-31 21:54:24 it is a little hard to imagine anyone else ever needing or wanting this. QNX4 systems aren't quite as popular as they used to be 2024-01-31 21:55:17 is there a forth out there targeting C89? 2024-01-31 23:07:23 3 2024-01-31 23:07:34 sorry, wrong window 2024-01-31 23:43:59 lispmacs[work]: iirc pForth https://github.com/philburk/pforth/blob/master/platforms/unix/Makefile#L28 2024-01-31 23:44:22 ah, you already were mentioning pforth earlier 2024-01-31 23:44:23 sorry. 2024-01-31 23:45:21 no worries, thanks for the help. pForth is the one I'm working with, but it targets C99 and this system is pre-C99