schaub@sugar.UUCP (Markus Schaub) (10/30/87)
ANNOUNCEMENT:
// //
// M2Amiga //
\\ // A new single pass Modula-2 compiler for the Amiga \\ //
\X/ \X/
M2Amiga the ultimate Modula-2 compiler for the Amiga is available now! This
compiler is derived directly from Professor Wirth's new single pass compiler
and has been adapted to the Amiga environment by the same team that released
the public domain ETHZ compiler on Fish Disk #24. Since the release of this
version a lot of changes had been made to fit optimally into the Amiga
environment.
M2Amiga works with version 1.2 of the Amiga operating system and runs on the
Amiga 500, Amiga 1000 and on the Amiga 2000 with at least one disk drive and
at least 512k of RAM. The system can be used either from the CLI (Command
Line Interface) or from within the workbench environment
This system comprises:
- an English or German language User Guide which explains in detail how the
system works, describes the basic modules and contains all interfaces with
the Amiga operating system as Modula-2 definitions. This documentation and
the English introductory guide allow both the beginner and the advanced
user to find the information he or she needs quickly and easily.
- a single pass compiler which produces 68000 machine code from standard
ASCII files at high speed. It can generate on request code to test array
limits, stack limits, overflow and missing return instructions etc. The
compiler does not interrupt on errors but continues compilation, noting
any further ones. Exceptionally accurate error messages are recorded in a
file for later display by the editor.
- mc68000 specific operations as reading and writing registers, inline 68000
instructions, FFP representation of REAL numbers (together with IEEE) are
supported by the compiler. Also supported are double precision types. ROM
calls (Exec, Intuition etc) DO NOT REQUIRE intermediate code.
- a run-time system takes into account the special conditions of a multi-
tasking system. Program crashes (division by 0, address errors etc.) are
trapped, all open files are closed and all allocated memory is released.
- an editor derived from microEmacs that places the cursor at the error and
reports the error in plain text. Menus and error messages are displayable
in either German or English.
- a linker which automatically searches for all the implementation modules
belonging to a module and combines them into a program which can run
either from the workbench environment or from the CLI.
- all definitions relating to the Amiga operating system. The definitions
follow the official definitions for the C programming language in
structure and nomenclature. Modula-2's much more stringement data typing
has been used in these definitions wherever possible. Remember: NO OBJECT
files with intermediate code needed!
- a large number of basic libraries: Arguments, ASCII, Conversions,
Coroutines, FileNames, FileSystem, FFPConversions, Heap, InOut, MathLib0,
MathLibLong, RandomNumbers, RealConversions, Storage, Strings, Terminal,
TextWindows and many more.
- even more: additional utilities are available for this basic package. There
is a loader with a source level debugger, a converter for standard Amiga
object files and further libraries which are extremly useful for program
development.
The single pass compiler, the user-friendly run-time system and the absence
of intermediate code for ROM calls makes this system very suitable for
efficient program development on the Amiga.
M2Amiga is available in its German version since August 87 and Interface
Technologies Corporation and I are very proud to announce this product now
on the American market.
M2Amiga costs $199 (+$5 for shipping and handling) and is available from
Interface Technologies Corporation further info (713) 523 8422 Markus
3336 Richmond, Suite 323 orders (800) 922 9049
Houston, Tx 77098
Also available:
- a demo version for limited programs and with just a few libraries.
Cost: $5 (+$1 for shipping and handling)
Will be on a Fish Disk soon.
In Europe:
A.+L. Meier-Vogt, Im Spaeten 23, CH 8906 Bonstetten/ZH, +41 1 700 3037
Being one of the developers of this product I'll be happy to answer your
questions by e-mail, mail or on the phone.
Markus Schaub
M2Amiga Developercs162ffl@sdcc18.ucsd.EDU (John Schultz) (11/01/87)
How does the M2Amiga Compiler compare to the Benchmark compiler from Oxxi? It too is a one pass emacs integrated compiler...I have been using it for a week without finding any major bugs (and the version I have is pre-release). Supported and developed in the US by Leon Frenkel and Oxxi, Inc. I am an ex-TDI user and am no way associated with Oxxi, Inc., just a very impressed user. The Benchmark compiler is advertised at 10000 lines per minute with 30000 lines in bursts. What are the M2Amiga Specs? Curious, John
schaub@sugar.UUCP (Markus Schaub) (11/05/87)
In <796@sdcc18.ucsd.EDU>, cs162ffl@sdcc18.ucsd.EDU (John Schultz) writes: > How does the M2Amiga Compiler compare to the Benchmark compiler from > Oxxi? It too is a one pass emacs integrated compiler...I have been No, compiler, linker, editor etc are standalone programs. No hot-keys. Compiler and linker support interactive mode, where you can run each program in its own CLI window and have the same effects. I know Benchmark and I really have problems on my 512k Amiga. M2Amiga was totally developed on 512k/2 drive machines. > using it for a week without finding any major bugs (and the version > I have is pre-release). Bugs, well I found some, I don't know if you would call them 'major bugs'. > Supported and developed in the US by Leon Frenkel and Oxxi, Inc. I doubt this is 100% true. I found some famous Wirth bugs in the compiler. I have reason to believe that Leon Frenkel uses Wirth's source too, just without mentioning it. M2Amiga is developed in Switzerland and I support it here in the US. I'm one of the developers, I'm a swiss guy, too. Have you ever heard anything bad about Swiss quality? :-) > I am an ex-TDI user and am no way associated with Oxxi, Inc., just a > very impressed user. I acknowledge the idea of integrating everything into the editor. > The Benchmark compiler is advertised at 10000 lines per minute with > 30000 lines in bursts. What are the M2Amiga Specs? Lightning fast, same compiler (basically), same speed... M2Amiga uses a more compact symbol file which takes a little more time to read in. The M2Amiga linker is faster (no search for files as Intuition.obj needed). Amiga specific programs (based on Intuition/Dos/Exec/etc) are more compact in M2Amiga 'cause there is no intermediate code for ROM calls which has to be linked to the object file. Further all OpenLibrary/CloseLibrary calls are done by the run-time system. It is possible to write: MODULE slowDown; FROM Dos IMPORT Delay; BEGIN Delay(10000) END slowDown. NOTE: only libraries you use are opened, works also with disk libraries. Also it is very easy to write your own interfaces to private or commercial libraries No Assembly needed, just parameter placing and library offset,and there you go! > Curious, > John Ask and you'll get an answer! Any more questions any other curious people? ---- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // This routine does no error-checking. If your delta values specify \\ // some far corner of the universe, Intuition will attempt to size your \X/ window to that far corner. Because of the distortions in the space - time continuum that can result from this, as predicted by special relativity the result is generally not desirable. (RKM II A-165 SizeWindow)
haitex@pnet01.cts.com (Wade Bickel) (11/10/87)
If the M2Amiga Linker works as you suggest, isn't the prep code
which must be generated prior to the call to a ROM routine redundantly
created at every call of the same routine. I can see this being faster,
but not more compact.
I am currently a beta-tester for the Benchmark compiler. Thus far
it has been very impressive, and I only discovered one bug, a very
minor one which was fixed for the release. If you properly configure
the startup file and disk, it is possible to work with only one drive
and 512K, if your work needs are small to moderate. But I would not
generally recomend it.
Hopefully I will get a copy of M2Amiga in the near future. I am
still open minded and if it is as good as you say when compared to
Benchmark I will admit it. But if it is'nt...
Thanks,
Wade.
PS: Aside from being an uncompensated beta-tester of the
Benchmark compiler I have no other assc. with either
Leon Frenkel or OXXI, Inc.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMdaveh@cbmvax.UUCP (Dave Haynie) (11/11/87)
in article <1982@crash.CTS.COM>, haitex@pnet01.cts.com (Wade Bickel) says: > Xref: cbmvax comp.sys.amiga:10462 comp.lang.modula2:509 > > If the M2Amiga Linker works as you suggest, isn't the prep code > which must be generated prior to the call to a ROM routine redundantly > created at every call of the same routine. I can see this being faster, > but not more compact. It could be a close call, size wise. I'm not sure about M2 calling conventions, but in C, all function arguments are pushed on the stack. The stub from Amiga.Lib pops these stack arguments into the appropriate registers, loads the library base into A6, then calls the appropriate library routine relative to that library base. If a compiler can generate an alternate calling convention for library routines, based on specific knowledge that the routine is a library routine, all the stack stuff (compiler pushes for function call, stub pops for library call) can be eliminated. The in-line library call still has to get the right arguments into registers, but in most cases either they're already in registers, or they'd have to pass through registers on the way to the stack, so this isn't extra work. Exclusive of argument handling, the setup for library call is only one or two extra instructions over the normal function call. > Hopefully I will get a copy of M2Amiga in the near future. I am > still open minded and if it is as good as you say when compared to > Benchmark I will admit it. But if it is'nt... In any case, it looks like Amiga-based M2 compilers are evolving at least as quickly as C compilers, making M2 a really viable language for the Amiga. I bought TDI way-back-when, and was throughly unimpressed. I've been using Lattice since then, and their new compiler is a pretty good one. But from what I've been reading about the state of M2, I'm just about ready to reconsider it again, and may soon spring for M2Amiga, or possibly BenchMark if they ever figure out who really owns that sucker. > > Wade. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat
schaub@sugar.UUCP (Markus Schaub) (11/13/87)
In article <1982@crash.CTS.COM>, haitex@pnet01.cts.com (Wade Bickel) writes: > > If the M2Amiga Linker works as you suggest, isn't the prep code > which must be generated prior to the call to a ROM routine redundantly > created at every call of the same routine. I can see this being faster, > but not more compact. The code for a ROM call is exactly the same as the code for a procedure call to a prodecure of an other module. The placing of parameters into registers doesn't make a big difference. With other compilers you have an external call to the assembler stub popping parameters into registers and eventually pushing results back on the stack again and the basic ROM call. Simplified: The time others arrive in their stubs we arrive at the function in ROM. A German jounalist doing some reseach on this came up with following figures. machine cycles for a Library Call. TDI ~250, Manx ~140, M2Amiga 94, he complained because the optimal Assembler call only uses 74 cycles. This still leaves some space for improvement :-) > > Hopefully I will get a copy of M2Amiga in the near future. I am > still open minded and if it is as good as you say when compared to > Benchmark I will admit it. But if it is'nt... > You won't be disappointed, I hope. M2Amiga is in stock, should I reserve a copy for you :-) // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/15/87)
:The code for a ROM call is exactly the same as the code for a procedure call :to a prodecure of an other module. The placing of parameters into registers :doesn't make a big difference. With other compilers you have an external call :to the assembler stub popping parameters into registers and eventually pushing :results back on the stack again and the basic ROM call. : :Simplified: The time others arrive in their stubs we arrive at the function in :ROM. : :A German jounalist doing some reseach on this came up with following figures. :machine cycles for a Library Call. :TDI ~250, Manx ~140, M2Amiga 94, he complained because the optimal Assembler :call only uses 74 cycles. This still leaves some space for improvement :-) Well, I wouldn't get too caught up in it. For one thing, those numbers are obviously averages over quite a few different calls, because things like Remove() from assembly take maybe 22 cycles of overhead (loadregister-4, jsr-18) in the call... common RTS and meat not included. If you look carefully, I think you will find that the library calls that run quickest take fewer arguments and thus less overhead, and the library calls that take more arguments generally take longer to complete anyway, so the overhead can almost be thought of as a straight percentage of the execution time for the call. This straight percentage is going to be very low, so optimizing from 140 to 74 isn't going to be noticeable at all. -Matt
schaub@sugar.UUCP (Markus Schaub) (11/15/87)
In article <2730@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <1982@crash.CTS.COM>, haitex@pnet01.cts.com (Wade Bickel) says: > > Xref: cbmvax comp.sys.amiga:10462 comp.lang.modula2:509 > > created at every call of the same routine. I can see this being faster, > > but not more compact. > It could be a close call,size wise.I'm not sure about M2 calling conventions, > but in C, all function arguments are pushed on the stack. The stub from Same in Modula-2, only difference: M2 routines clean the stack, fixed number of parameters (in difference to C) makes this possible. > Amiga.Lib pops these stack arguments into the appropriate registers, loads > the library base into A6, then calls the appropriate library routine relative In M2Amiga the library base is loaded pc relative not from an absolute address, and the library offset is coded as a 16-bit value instead of a 32-bit external absolute value. This the difference to C stubs. > to that library base. If a compiler can generate an alternate calling > convention for library routines, based on specific knowledge that the routine Thanx, to precompiled definitions (symbol files) > the setup for library call is only one or two extra instructions over the > normal function call. Almost exactly, I wish this were my words, but although being 4 months in the States now my English could need some lessons.We don't need extra instructions because M2Amiga also loads basepointers for imported modules the same way. > In any case, it looks like Amiga-based M2 compilers are evolving at least as > quickly as C compilers, making M2 a really viable language for the Amiga. I hope my friends back in Switzerland will soon release the source level debugger! There will be real competition to C! Hey Claudio, maybe you can tell us about the state of the debugger. > > Wade. > -- > Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh -- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
peter@sugar.UUCP (Peter da Silva) (11/16/87)
> > In any case, it looks like Amiga-based M2 compilers are evolving at least as > > quickly as C compilers, making M2 a really viable language for the Amiga. > > I hope my friends back in Switzerland will soon release the source level > debugger! There will be real competition to C! How about statically initialised structures? How do you do the equivalent in Modula of the 'C': struct Gadget STD_Gadget[GADGETS] = { /*NEXT, LFT, TP,WDTH, H, FLAG, ACT, TYP, REND, Z, TXT, Z, SPEC, ID, Z */ { G(1), IN1,TP1, WD1,HT, SF, SA, SG, Z, Z, Z, Z, SI(0), 0, 0 }, { G(2), IN1,TP2, WD1,HT, SF|SEL, SA, SG, Z, Z, Z, Z, SI(1), 1, 0 }, { G(3), IN1,TP3, WD1,HT, SF, SA, SG, Z, Z, Z, Z, SI(2), 2, 0 }, { G(4), IN3,TP4, WD3,HT4,BF1, BA, BG,BB(0), Z, TOK, Z, Z, 3, 0 }, { G(5), IN4,TP4, WD4,HT4,BF2, BA, BG,BB(1), Z, TNO, Z, Z, 4, 0 }, { G(6), IN6,TP4, WD6,HT4,BF1, BA, BG,BB(2), Z, TVL, Z, Z, 5, 0 }, { NULL, IN5,TP5, WD5,HT5,PF, PA, PG, IMAG, Z, Z, Z, PROP, 6, 0 } }; -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
schaub@sugar.UUCP (Markus Schaub) (11/16/87)
In article <1069@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > How about statically initialised structures? How do you do the equivalent in > Modula of the 'C': > > struct Gadget STD_Gadget[GADGETS] = { > /*NEXT, LFT, TP,WDTH, H, FLAG, ACT, TYP, REND, Z, TXT, Z, SPEC, ID, Z */ > { G(1), IN1,TP1, WD1,HT, SF, SA, SG, Z, Z, Z, Z, SI(0), 0, 0 }, We know about this problem, a guy in Switzerland is working on some kind of language extension. Release date unknown. This moment just one possibility: PROCEDURE MyWindow; (* $E- no entry/exit code for this procedure please *) BEGIN INLINE( 0, 5, 0, 4, 0FFE0H, ... your data ... ) END MyWindow; ... wp:=OpenWindow(ADR(MyWindow)); ... Not very nice, but it works! -- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/16/87)
>Same in Modula-2, only difference: M2 routines clean the stack, fixed number >of parameters (in difference to C) makes this possible. You mean the calee restores the stack rather than the caller? That's an interesting nitpick, but the designers of C wanted programmers to be able to make calls to the same routine with a varying number of arguments. This doesn't make the code any slower, just slightly longer. > Amiga.Lib pops these stack arguments into the appropriate registers, loads > the library base into A6, then calls the appropriate library routine relative >In M2Amiga the library base is loaded pc relative not from an absolute address, >and the library offset is coded as a 16-bit value instead of a 32-bit external >absolute value. This the difference to C stubs. Hate to say this, but it's pc relative in Aztec as well, at least with the small code model. and the library offset is coded as a 16 bit value (you can't HAVE 32 bit offsets with the 68000). Still, I admit the library interface in both Aztec and Lattice are somewhat inefficient. Lattice will fix this in 4.0, hopefully Aztec will come up with something to (but as I said before the overhead usually isn't worth optimization when compared to actual execution time of the library function). >> In any case, it looks like Amiga-based M2 compilers are evolving at least as >> quickly as C compilers, making M2 a really viable language for the Amiga. > >I hope my friends back in Switzerland will soon release the source level >debugger! There will be real competition to C! >Hey Claudio, maybe you can tell us about the state of the debugger. All I can say is..... Go for it! -Matt
schaub@sugar.UUCP (Markus Schaub) (11/17/87)
In article <8711142308.AA01690@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > This straight percentage is going to be very low, so optimizing > from 140 to 74 isn't going to be noticeable at all. > > -Matt Noticeable? I never said you will notice any change, all compilers produce fast (very fast :-) code. But there might be a difference for REAL computation where FFP and MathIEEDoubbas routines are called. But still you're right. Faster calls don't make faster routine execution. Let's speed up the libraries! -- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
haitex@pnet01.cts.com (Wade Bickel) (11/17/87)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:The code for a ROM call is exactly the same as the code for a procedure call >:to a prodecure of an other module. The placing of parameters into registers >:doesn't make a big difference. With other compilers you have an external call >:to the assembler stub popping parameters into registers and eventually pushing >:results back on the stack again and the basic ROM call. >: >:Simplified: The time others arrive in their stubs we arrive at the function in >:ROM. >: >:A German jounalist doing some reseach on this came up with following figures. >:machine cycles for a Library Call. >:TDI ~250, Manx ~140, M2Amiga 94, he complained because the optimal Assembler >:call only uses 74 cycles. This still leaves some space for improvement :-) > > Well, I wouldn't get too caught up in it. For one thing, those >numbers are obviously averages over quite a few different calls, because >things like Remove() from assembly take maybe 22 cycles of overhead >(loadregister-4, jsr-18) in the call... common RTS and meat not included. >If you look carefully, I think you will find that the library calls that run >quickest take fewer arguments and thus less overhead, and the library calls >that take more arguments generally take longer to complete anyway, so the >overhead can almost be thought of as a straight percentage of the execution >time for the call. > > This straight percentage is going to be very low, so optimizing >from 140 to 74 isn't going to be noticeable at all. > > -Matt > Seems to me any cycles are important. Perhaps not for general code, but when it comes to the decision as to weather or not to use assembly, this could make a difference. Wade. PS: Matt, have you tried Modula-2? I know your a C programmer, and just wondered if you'd given M2 a look. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
kent@xanth.UUCP (11/18/87)
[They're talking machine cycles for a procedure call here, folks] In article <1074@sugar.UUCP> schaub@sugar.UUCP (Markus Schaub) writes: >In article <8711142308.AA01690@cory.Berkeley.EDU>, >dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> >> This straight percentage is going to be very low, so optimizing >> from 140 to 74 isn't going to be noticeable at all. >> >> -Matt > >Noticeable? I never said you will notice any change, all compilers >produce fast (very fast :-) code. But there might be a difference for >REAL computation where FFP and MathIEEDoubbas routines are called. But >still you're right. Faster calls don't make faster routine execution. >Let's speed up the libraries! Well, yes, lets do, but the rest of the argument is pretty bogus. The speed of procedure calls, if you are aware of it and care about speed of your program, changes the STYLE of your programming. No matter what the language, I find myself, as a fanatic modular programming devotee, frequently writing procedures containing only ONE executable line. Why? Because it makes the code much more readable to put a one word name for what I want done in the calling routine, and hide the grungy details in a separate procedure. My goal, not always achieved, is to have the executable code of any procedure fit on a single, not too busy screen. In terms of program maintenance, this is a Good Thing. But, if the cost of that procedure call is high relative to the amount of code being executed, I'm suddenly reluctant to Do Things Right. So improve the libraries all you want, but remember, high procedure call overhead has negative affects beyond just the extra time spent; it can actually worsen coding style. Thus, time spent improving this area is also very worth while. Thanks for listening. Kent, the (impoverished) man from xanth. "Computer - a mass occupying my desk with an unusual attraction for money." (me) "Sometimes I think mine is a black hole, located in the general vicinity of my checkbook." (Blaine Gardner, in response.)
haitex@pnet01.cts.com (Wade Bickel) (11/18/87)
schaub@sugar.UUCP (Markus Schaub) writes: >In article <1069@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: >> How about statically initialised structures? How do you do the equivalent in >> Modula of the 'C': >> >> struct Gadget STD_Gadget[GADGETS] = { >> /*NEXT, LFT, TP,WDTH, H, FLAG, ACT, TYP, REND, Z, TXT, Z, SPEC, ID, Z */ >> { G(1), IN1,TP1, WD1,HT, SF, SA, SG, Z, Z, Z, Z, SI(0), 0, 0 }, > >We know about this problem, a guy in Switzerland is working on some kind of >language extension. Release date unknown. This moment just one possibility: > >PROCEDURE MyWindow; (* $E- no entry/exit code for this procedure please *) >BEGIN > INLINE( > 0, 5, 0, 4, 0FFE0H, ... your data ... > ) >END MyWindow; >... > wp:=OpenWindow(ADR(MyWindow)); >... > >Not very nice, but it works! > >-- > // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 > // M2Amiga Developer trying to get back the money I paid for my >\\ // Amiga by selling a few M2Amiga. > \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098 UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
haitex@pnet01.cts.com (Wade Bickel) (11/18/87)
schaub@sugar.UUCP (Markus Schaub) writes: >In article <1069@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: >> How about statically initialised structures? How do you do the equivalent in >> Modula of the 'C': >> >> struct Gadget STD_Gadget[GADGETS] = { >> /*NEXT, LFT, TP,WDTH, H, FLAG, ACT, TYP, REND, Z, TXT, Z, SPEC, ID, Z */ >> { G(1), IN1,TP1, WD1,HT, SF, SA, SG, Z, Z, Z, Z, SI(0), 0, 0 }, > >We know about this problem, a guy in Switzerland is working on some kind of >language extension. Release date unknown. This moment just one possibility: > >PROCEDURE MyWindow; (* $E- no entry/exit code for this procedure please *) >BEGIN > INLINE( > 0, 5, 0, 4, 0FFE0H, ... your data ... > ) >END MyWindow; >... > wp:=OpenWindow(ADR(MyWindow)); >... > >Not very nice, but it works! > >-- > // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 > // M2Amiga Developer trying to get back the money I paid for my >\\ // Amiga by selling a few M2Amiga. > \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098 ==================================================================== Seems like a good solution to me. I'd like to know more about this $E option. If it is clean, and relocatable (??) this should work quite well. It would be nice to coerce the structure pointer into a record, which should work. ie, Rather than ignoring type checking using ADR, couldn't you say wp := OpenWindow(NewWindow(MyWindow)); at least I think this might work. When will the M2Amiga Source Level Debugger be released? Will it be included in the $195 price? What libraries are included? Thanx, Wade. PS: sorry, a few bad characters on the line caused an un- finished version of this comment to be sent. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
schaub@sugar.UUCP (Markus Schaub) (11/18/87)
[ ATTENTION COMMERCIAL INFO ON M2AMIGA ]
Sorry about this kind of info posted to the net, but I get a lotta messages
with the same questions.
Problems with M2Amiga prices! Sorry about this.
The price I called retail price in the announcement is just an introductory
offer. Retail will be $249.
M2Amiga, now -> Dec 31, 1987 $199
after Dec 31, 1987 $249
Dealers also profit on orders until end of the year.
The same final product -- We do not sell prereleases!
We do not expect an update before mid 88.
Upgrade policy: Registered users are informed and can get the upgrade for
a very reasonable price.
Add $10 for shipping and handling. Texas resident add 8% sales tax.
Check or Plastic welcome. Orders: (800) 922 9049
Checks made out to Interface Technologies Corp, see address in disclaimer.
M2Amiga is in stock, orders are shipped the next day.
For Flyers, send me your mailing address.
--
// Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422
// M2Amiga Developer trying to get back the money I paid for my
\\ // Amiga by selling a few M2Amiga.
\X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098toebes@sas.UUCP (11/18/87)
In article <8711161753.AA05748@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Still, I admit the library interface in both Aztec and Lattice are > somewhat inefficient. Lattice will fix this in 4.0, hopefully Aztec will > come up with something to (but as I said before the overhead usually isn't > worth optimization when compared to actual execution time of the library > function). > -Matt Actually you mean "Lattice fixed this in 4.0" because it has been out for almost a month. The overhead for the call is quite significant, especially for short programs. With the 4.0 compiler I have been able to reduce frags to 528 bytes and avail to 748 due to the inline code. When lines has been compiled with the builtin functions it runs noticably faster. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti-sel!sas!toebes-----*/ /*------------------------------------------------------------------------*/