a665@mindlink.UUCP (Anthon Pang) (06/09/90)
Hey, did anyone else read the Bug Bytes section in the Vol5 Iss6 of Amazing
Computing ? If you own Avant-Garde's Benchmark Modula-2 for the Amiga, you'll
recognize the name: LEON FRENKEL.
According to Mr Frenkel, he & a "partner", established Preferred Technologies,
and acquired M2Sprint from M2S. He emphasized, "separate" companies...he
stated, the compilers would not be merged, and implied that both compilers
would be supported. So where's the competition? the incentive to produce a
better product? (ala C wars between Manx & Lattice...Dice :))--TDI...no
contest, M2Amiga...they don't follow the traditional Amiga includes method of
naming type identifers--ie TopEdge vs topEdge.
M2Sprint looked to be a Benchmark Buster...boasting more features, better
optimization, and more libraries...but alas, for more bucks. Martin
Taillefer, formerly of M2S, posted to comp.lang.modula2, that he was
"working on another [Modula-2] programming environment for the Amiga", to be
released in the spring. He also noted, that development of version 2.0 of
M2Sprint & the debugger, were halted when he left M2S, in October 89.
If you're considering getting into programming in Modula-2 on the Amiga, wait
a while...when the dust clears after the release of Martin's new product and
the forthcoming os 2.0 upgrade from Avant-Garde, a clear victor will arise
(btw, my money's on Martin...hmmm, is net.betting a net.offense?).
PS. I do own the Benchmark compiler...it is a good product but I have nits
with it:
1) doesn't optimize out link a5,-$0000 / unlk a5 pair
2) can't generate pure code
3) doesn't have a "smart linker"
4) the 64K limit applies to TYPEs, too...so AllocMem'ing is not a solution.
Except for #1, the chances of #2-4 making it into a compiler upgrade, anytime
rsn, is close to NIL, IMHO.
PPS. If you've got credit on CIS, Avant-Garde offers a "try before you buy"
offer on their Source Level Debugger, BUT, ONLY if you download it from their
library section on CI$ (ie don't pirate it...actually, don't pirate, period).
Also, email through the Compuserve gateway to Avant-Garde/Leon Frenkel is
possible through the following address: 76004.2002@compuserve.com
PPPS. There's also a few interesting archives on xanth, for the Benchmark
system, available for ftp'ing. In the /incoming/amiga/modula2_benchmark
directory (well, there was, when I looked, a couple weeks ago):
bm2arp.lzh - arp.library glue routines
bm2asm.lzh - alternate method of interfacing assembly
code--especially if your assembler isn't
Metacomco compatible
bm2ced.lzh - Resident program to launch compiler and
linker from CED...binds commands to
Arexx function keys (so you'll need Arexx)
bm2cr.lzh - co-routines module (to appear in the next
release of the Benchmark libraries)
bm2lib.lzh - os 1.3 Benchmark libraries revision
bm2sp.lzh - process spawning code
These appear to be a compilation from different sources. My thanks to the
fine people who take the time to upload all sorts of useful things to xanth.
I hope we'll see some new Schwartz demos when school's out for Eric :)
----
######
# # Wow! I can see! This VISOR Video Toaster/Oven attachment is great...
{||||||} ...oops, maybe I shouldn't...it's not UFPCC approved yet.
| `' |
\ ~~ / Naahhh. Besides, it makes better toast than the EnterBOING's
__| |___ food dispensers, too.
__\__/__/
A [just a Trekker with an Amiga]a665@mindlink.UUCP (Anthon Pang) (06/10/90)
> jcs@crash.cts.com writes: > Allocating memory (using AllocMem) *is* the solution. You can declare > your type as ARRAY[0..1] of mydata and don't use range checking (who does?). > The compiler will generate the correct code, all it needs to know is the > size of your data. > If the compiler does something like: > > add.w d0,d0 > add.w d0,d0 > > or > > lsl.w #2,d0 > > to do a *4 index for your array, then 64k is still a limit. I guess you've never disassembled the binaries generated by the Benchmark compiler/linker. The interpretation of the 64K limit depends on context... ...in the case of arrays, it is either the size of the data structure (64K bytes), or the range of the array index [0..65536]. With open arrays, the index limit is 65535 elements. With fixed arrays, the compiler WILL check against the VAR declaration. So, I say again, AllocMem'ing is NOT "the solution". (* The following code fragment will not compile with Benchmark M2, nor is it supposed to...its purpose is to demonstrate the "limits" of the compiler *) MODULE foo; FROM SYSTEM IMPORT ADDRESS; FROM Memory IMPORT AllocMem, MemReqSet, MemFast, MemClear; CONST s = 100000D; TYPE r = [0..1]; a = ARRAY r of CARDINAL; p = POINTER TO a; VAR x : p; PROCEDURE bar(z: ARRAY OF CARDINAL); BEGIN z[65535] := 2; (* yeah, but you disabled range checking *) z[65536] := 3; (* Illegal, index exceeds 2^16=65535 *) END bar; BEGIN x := AllocMem(s,MemReqSet{MemFast,MemClear}); x[32767] := 0; (* Illegal, index exceeds TYPE'd range *) x[65535] := 1; (* Illegal, index exceeds 2^15=32768 *) bar(x^); FreeMem(x,s); END test. -- _-=^=-_ |' ^ `| Ahhh! Multiple CLIs...a copy of K&R...a can of prune #\_ ^ _/# juice...the signs of a Klingon C programmer. #' ~T~ `# #\ /-\ /# GGRRR! But, where is your ridge?! your mark of __##\#//##___ ascension into the ranks of KlinGuru?! And, where @O@ \_/ \ are the Rom Kernel Manuals, you were supposed to @#@ A | to drop on your head?! Copyright 1990 Yet Another Stupid Sig Inc.
jcs@crash.cts.com (John Schultz) (06/11/90)
In article <2045@mindlink.UUCP> a665@mindlink.UUCP (Anthon Pang) writes: >PS. I do own the Benchmark compiler...it is a good product but I have nits [1-3 deleted] > 4) the 64K limit applies to TYPEs, too...so AllocMem'ing is not a solution. >Except for #1, the chances of #2-4 making it into a compiler upgrade, anytime >rsn, is close to NIL, IMHO. Allocating memory (using AllocMem) *is* the solution. You can declare your type as ARRAY[0..1] of mydata and don't use range checking (who does?). The compiler will generate the correct code, all it needs to know is the size of your data. If the compiler does something like: add.w d0,d0 add.w d0,d0 or lsl.w #2,d0 to do a *4 index for your array, then 64k is still a limit. John John
Martin@pnt.CAM.ORG (Martin Taillefer) (06/11/90)
>In article <3084@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >In article <2045@mindlink.UUCP> a665@mindlink.UUCP (Anthon Pang) writes: >> 4) the 64K limit applies to TYPEs, too...so AllocMem'ing is not a solution. >>Except for #1, the chances of #2-4 making it into a compiler upgrade, anytime >>rsn, is close to NIL, IMHO. > > Allocating memory (using AllocMem) *is* the solution. You can declare >your type as ARRAY[0..1] of mydata and don't use range checking (who does?). >The compiler will generate the correct code, all it needs to know is the >size of your data. Untrue. As you pointed out later in your message, the access technique used by the compiler can effectively limit various sizes. For one thing, record offsets are accessed with offset(An) which clearly limits records to 32K. Arrays are also limited to this size mainly due to stuff like open array parameters which require the compiler to pass a hidden array length (to support the HIGH() function). This hidden length is passed as a 16-bit value. Offset calculations within arrays are also performed with 16-bit airthmetic. -- ------------------------------------------------------------- Martin Taillefer INTERNET: martin@pnt.CAM.ORG BIX: vertex UUCP: uunet!philmtl!altitude!pnt!martin TEL: 514/640-5734