xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/09/90)
In article <13751@venera.isi.edu> rod@venera.isi.edu (Rodney Doyle Van Meter III) writes: [Some bitches, but overall praise, for BENCHMARK Modula-2] The integrated programming environment is really quick and convenient. From the emacs editor, F6 lets you name your main module (necessary in a separate compilation environment), F2 compiles the current module, F1 walks you through the errors, if any, in the editor, F3 links the modules and libraries (and is unbelievably fast), and F4 opens a small CLI window and test runs your program from it. If your program ends normally, a "gimme a carriage return" message shows up in the CLI window, and when you do, you're back in the editor, cursor unmoved. In small programs, I can frequently change code, compile, link and test it in 30 seconds or less, which really promotes incremental code development. My biggest worry with the product so far, though I haven't yet hit it as a problem, is the limit on single arrays and of total module data requirements of 64K (bytes?). On a nine and a half megabyte machine, an array size limit of 64K is a joke, and there is no immediately evident, straightforward way to get around it. >The main reason I'm writing, though, is to ask where you can get the >debugger! I'd love to have it, but the Amiga stores in SoCal say they >don't have it and can't get it. Order direct from: Avant-Garde Software 2213 Woodburn Plano, TX 75075 (214) 964-0260 Price I paid, including shipping, $159.95; this may have changed. Insert usual "only a happy customer" BS here. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jcs@crash.cts.com (John Schultz) (06/10/90)
In article <1990Jun8.181538.18276@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >My biggest worry with the product so far, though I haven't yet hit it >as a problem, is the limit on single arrays and of total module data >requirements of 64K (bytes?). On a nine and a half megabyte machine, >an array size limit of 64K is a joke, and there is no immediately >evident, straightforward way to get around it. > Declare a pointer to an array of your type, then allocate memory with AllocMem, and set the pointer to your memory. That's it. Arrays as big as you need. Use as: mydata^[index] := xxx. John
tmb@davinci.acc.Virginia.EDU (Thomas M. Breeden) (06/11/90)
In article <3074@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >In article <1990Jun8.181538.18276@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>My biggest worry with the product so far, though I haven't yet hit it >>as a problem, is the limit on single arrays and of total module data >>requirements of 64K (bytes?). On a nine and a half megabyte machine, >>an array size limit of 64K is a joke, and there is no immediately >>evident, straightforward way to get around it. >> > > Declare a pointer to an array of your type, then allocate memory with >AllocMem, and set the pointer to your memory. That's it. Arrays as big as you >need. Use as: mydata^[index] := xxx. > > > John This will not work. The disassembler window of the Benchmark Source Level Debugger shows code for ANY array reference to be generated with assumptions that the array is no bigger than 64K bytes since a word sized index register (or displacement for constant indices) is used in the generated code. (Maybe that should be 32K, since the M68000 uses signed indices). This is the same reason a module/procedure's data is limited. What you need to do is declare p:POINTER TO x, ALLOCATE(p, AsBigAsYouWant) and then do some "C style" processing: move p through the data, changing the pointer with address arithmetic (being careful to increment by SIZE(x)). Tom Breeden tmb@viginia.edu -->> Internet tmb@virginia -->> BITNET