gjc@mitech.COM (08/16/90)
I agree that I get sloppy with respect to sizeof(int) != sizeof(long). But a port of SIOD to a machine where sizeof(int) = 2 and sizeof(long) = 4 was done: The Macintosh under lightspeed C version 4.0 (This version is also available on BU.EDU in users/gjc/siod-v2*-hqx or *mac*) The trick was to use the REQUIRE ANSI PROTOTYPES mode. Then one was forced to create a prototype for each and every function. Jim O'Dell did the dirty work for me (he is a macintosh machovist, having ported FRANZ LISP a year ago and GNU UUCP recently). Once those prototypes were defined, and all the "%d" in printfs changed to "%ld" where needed, SIOD ran fine. Further work involved adding a SYSEVENTS POLL in the loop for EVAL and PRINT, and a stack-level check in EVAL and PRINT. Even stranger machines have had ports of SIOD. Somebody did a PRIME/PRIMOS port, and mentioned that different types of arguments were returned in different registers, so that prototypes were invaluable. Why don't I include the PROTOTYPES (SIOD_PROTO.H) in the main release? I guess I was bothered by the extra size of the source file involved, and the fact that not all compilers (e.g. SUN microsystems) will allow the use of prototypes. If you want to see a "machine" in which SIOD is *hopeless* try the SABER-C interpreted environment. At least in mode -g0 the stack marking code is completely useless. -gjc
bds@lzaz.ATT.COM (Bruce Szablak) (08/17/90)
In article <9008170327.AA21454@mailhost.samsung.com> gjc@mitech.com writes: >I agree that I get sloppy with respect to sizeof(int) != sizeof(long). > >But a port of SIOD to a machine where sizeof(int) = 2 and sizeof(long) = 4 >was done: The Macintosh under lightspeed C version 4.0 > >(This version is also available on BU.EDU in users/gjc/siod-v2*-hqx or *mac*) > Interesting. Linting the original code I see that it uses the difference between two pointers to calculate the size of the heap. Many C compilers return an int when pointers are subtracted from each other. This limits the size of the heap to what can be fit into an int. If sizeof(int) = 2 you are pretty limited. Another portability problem is that many names are not unique to seven characters. the the difference of t
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
In article <9008170327.AA21454@mailhost.samsung.com> gjc@mitech.com writes: > I agree that I get sloppy with respect to sizeof(int) != sizeof(long). > The trick was to use the REQUIRE ANSI PROTOTYPES mode. Prototypes make up for a multitude of sins. Unfortunately, we aren't all able to make use of them. One of these days... Another problem in SIOD comes from the heap management. All the RAM for the heap is allocated at startup. On a machine with 64K segments that leaves a 5000-element heap, which isn't enough to run the factorial test. If I continue to go with SIOD (I'm currently waiting for PSI so I can do a 3-way comparison with TCL, SIOD, and PSI) I'll be sure to fix that. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
thompson@CEBAF4.CEBAF.GOV (Al Thompson) (08/21/90)
> Another problem in SIOD comes from the heap management. All the RAM for the > heap is allocated at startup. On a machine with 64K segments that leaves > a 5000-element heap, which isn't enough to run the factorial test. If I > continue to go with SIOD (I'm currently waiting for PSI so I can do a 3-way > comparison with TCL, SIOD, and PSI) I'll be sure to fix that. Pardon my ignorance, but how do you intend to do that? Warmest Wishes For A Happy New Year, Your Friend and Good Buddy, Alfred Thompson Summer Intern (thompson@cebaf4.cebaf.gov) CEBAF Computer Center Work Phone: (804) 249-7041
peter@ficc.ferranti.com (Peter da Silva) (08/23/90)
I said: > > Another problem in SIOD comes from the heap management. All the RAM for the > > heap is allocated at startup. On a machine with 64K segments that leaves > > a 5000-element heap, which isn't enough to run the factorial test. If I > > continue to go with SIOD (I'm currently waiting for PSI so I can do a 3-way > > comparison with TCL, SIOD, and PSI) I'll be sure to fix that. In article <9008211348.AA16999@cebaf4.cebaf.gov> thompson@CEBAF4.CEBAF.GOV (Al Thompson) writes: > Pardon my ignorance, but how do you intend to do that? Off the top of my head: if I can't get a cell, allocate a new pair of arrays and treat them as part of the heap. When I get back to bottom, do a GC and compress the heap, freeing any arrays that are no longer needed. All pointers are already 32 bits, so that's not a problem. It's a little harder to operate with a non-contiguous heap, but it should be no slower. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com