U46050@UICVM.BITNET (JOHN ZAFIRIS) (03/01/89)
Hello all: I was just thinking about the whole nullfilling mess. Yeah, I know... not this again... Wait, wait, this might actually make sense: To Atari Corp: What do you think of the idea of allowing the program that is run to decide if it wants the memory blanked? I know that the code that you are now using is really fast but there is still a noticible real time delay when running programs (smaller ones especially) on a machine with a few meg of memory. Here's the proposal: Atari, write 4 instructions worth of code into those new, amazing, almost-as-good-as-sliced bread v.1.4 ROMS that check the last 4 bytes of the program that was just loaded (I'm sure that 4 instructions are able to fit into that 192K or ROM). If those last 4 bytes are some magic value, say 628318530 (2*pi, yes, I know, really original...) then the memory clearing code is just ignored. This would make all present software automatically compatible and all future software better written (people will think before writting code that assumes what it shouldn't (blank mem) (yes, I know, K&R says this and K&R says that... hooey! I don't like C anyway). Best of all, this is completely optional. The software developer who wants the extra speed can get it and he/she who doesn't does not have to do anything... just as if it were still 1985. Atari, think about it and even better, do it. Everybody else, what do you think? Is this a brilliant idea or (embarassment:) has this been suggested before or is it for some reason stupid and it will never work? either way, let me know... ...John Zafiris
david@bdt.UUCP (David Beckemeyer) (03/03/89)
In article <8903010551.AA25974@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET (JOHN ZAFIRIS) writes: >Here's the proposal: Atari, write 4 instructions worth of code into >those new, amazing, almost-as-good-as-sliced bread v.1.4 ROMS that check >the last 4 bytes of the program that was just loaded (I'm sure that 4 >instructions are able to fit into that 192K or ROM). If those last 4 >bytes are some magic value, say 628318530 (2*pi, yes, I know, really >original...) then the memory clearing code is just ignored. ... [ Rest Deleted ] Last four bytes of which part of the program just loaded? The last bytes of the Text, Data, BSS, Symbols, or what? If it's the last bytes of the file, these are currently undefined, and in fact they're used by MWC executables. Who puts the four bytes there? The linker? The User? What's to guarantee that the magic number isn't there now in some executable file? Basically I think this is old news. Forget it. There's a lot more important things for Atari to do with the ST; like how about multichannel DMA and a real MMU and some hardware for that Mega Bus and an expansion box for it and some ATARI SUPPORTED network hooks built into the OS and FORWARD SLASHES and virtual file systems and ... :-) -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
) (03/06/89)
In article <526@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >In article <8903010551.AA25974@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET (JOHN ZAFIRIS) writes: >>[Start deleted] >>instructions are able to fit into that 192K or ROM). If those last 4 >>bytes are some magic value, say 628318530 (2*pi, yes, I know, really >>original...) then the memory clearing code is just ignored. ... >[ Rest Deleted ] >Last four bytes of which part of the program just loaded? The last bytes >of the Text, Data, BSS, Symbols, or what? If it's the last bytes of the >file, these are currently undefined, and in fact they're used by MWC >executables. Who puts the four bytes there? The linker? The User? >What's to guarantee that the magic number isn't there now in some >executable file? I think the chances, that the MAGIC number matches some long and that the program _also_ requires zeroing of the data space are pretty much '0'. On the other hand isn't the blitter (I don't have one) able to do zeroing of data? (At least it should be). And, aren't there some unused bytes in the .PRG header of every executable file ? That could be a better place to add a flag. > >Basically I think this is old news. Forget it. There's a lot more News I never heard, but then I just hopped out of the cradle... >important things for Atari to do with the ST; like how about multichannel >DMA and a real MMU and some hardware for that Mega Bus and an expansion >box for it and some ATARI SUPPORTED network hooks built into the OS >and FORWARD SLASHES and virtual file systems and ... :-) But since they are _obviously_ not able to do (*) that, I would be grateful for the nullfilling thing (and probably a challenging task for Atari programmers too (***)). Natuerlich! (*) A big "har har" (**) here. (Yes I did see the ':-)' there.) (**) use a slightly bitter, cynical undertone (***) har har, sorry. Georg Wallmann (Natuerlich!) cgw@trillian.irb.informatik.uni-dortmund.de "Lasst dicke Frauen um mich sein" ...uunet!mcvax!unido!trillian!cgw (moving in March/zieht im Maerz um) ---------------[ cgw[%trillian]@[ex]unido.<uucp|bitnet> ]------------------
pa2183@sdcc15.ucsd.edu (pa2183) (03/07/89)
This is not so much about 'nullfilling' as strange startup problems. I have had your MT C-shell as well as the Micro C-shell for sometime now. I have recently downloaded the Sozobon C stuff. The *.TTP programs work under the Micro C-shell but not under MT C-shell. Atfer some investigation it appears that the Sozobon startup uses some interresting methods to find the name of the program that was 'pexec-ed'. I would like to know if this code uses standard things 'everyone knows' in the atari world or do I have an old version of MT C-Shell or this is what I get for using 'free' stuff. Thank You John Clark Internet: pa2183@sdcc15.ucsd.edu
danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) (03/15/89)
In article <8903010551.AA25974@ucbvax.Berkeley.EDU>, U46050@UICVM.BITNET (JOHN ZAFIRIS) writes: > (people will think before writting code that > assumes what it shouldn't (blank mem) (yes, I know, K&R says this and > K&R says that... hooey! I don't like C anyway). Best of all, this is K&R say nothing about clearing memory. Only static variables are cleared and this is done by the compiler. What K&R say about memory allocated by malloc is that the contents are garbage and that it must be initialize by the programmer. Anyone programming in C that assumes that malloced memory is zero is making a very big mistake. Dan Wilson
john@stag.UUCP (John Stanley) (03/17/89)
[danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) writes...] > K&R say nothing about clearing memory. Only static variables are > cleared and this is done by the compiler. Half right Dan. K&R, page 198, paragraph 3 (sort of): "Static and external variables which are not initialized are guaranteed to start off as 0; automatic and register variables which are not initialized are guaranteed to start off as garbage." Uninitialized data space is cleared (typicaly) by the operating system for security reasons and to prevent having to have each and every program do it (not the compiler)... On the few systems where the OS is known to not clear the uninitialized data space, then a part of the startup module in the program is used, but again, it's not "the compiler" that does the clearing.... > Anyone programming in C that assumes that malloced memory is zero is > making a very big mistake. Agreed! Even in the example code shown in K&R, no attempt is made to clear allocated memory. (That's what calloc() is for... :^) > Dan Wilson --- John Stanley <dynasoft!john@stag.UUCP> Software Consultant / Dynasoft Systems
mowgli@dinghy.cis.ohio-state.edu (Mowgli Assor) (03/23/89)
(Just a little note, this is my first post to the net, so excuse any wierd stuff, other than my personality 9-) In article <0217890118120601@dynasoft.UUCP> dynasoft!john@stag.UUCP (John Stanley) writes: >[danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) writes...] > [...Stuff Deleted...] > >> Anyone programming in C that assumes that malloced memory is zero is >> making a very big mistake. > > Agreed! Even in the example code shown in K&R, no attempt is made to >clear allocated memory. (That's what calloc() is for... :^) > >> Dan Wilson > >--- >John Stanley <dynasoft!john@stag.UUCP> >Software Consultant / Dynasoft Systems I must say "absolutely agreed". I've been debugging a program written with Lattice for about 2 weeks now, & this discussion saved my bacon! <Grin> I was getting a little problem where one of the pointers was ending up in the 7+Million range (on a 512K machine 9-( ). I could not find any logical (or otherwise 9-) explanation for it. Then I realized that I was sort of assuming that the malloc() calls were returning zeroed out memory, & I was only checking for NULLs. <Smile> I went back & preset the pointers to NULLs before using them, & the problem has since disappeared. So, THANK YOU for reminding me, guys. Later, <Mowgli> -=- Address: mowgli@puffer.cis.ohio-state.edu (Mowgli Assor in real life) The 2 precepts of Semi-Divinity: (1) Mind Thine Own Business. (2) Don't Worry About It.