jchapman@watcgl.UUCP (john chapman) (02/05/85)
I would like to solicit peoples opinions of Modula inplementations
for MS-DOS systems. If there is sufficient response I'll post a
summary. Of particular interest to myself are opinions on the
quality of the Volition (do they still exist?) and Logitech versions,
or any other implementations (I don't know of any other than Mod.Corp.
which I am now trying out). Useful info/comments might/would be:
1. price, availability etc.
2. available utilities (debugger?)
3. level of company support
4. compatibility/extensions etc.
5. memory, disk requirements
6. speed of compiler
7. speed of code produced
8. native code or m-code?
9. Is the compiler just another DOS program or do you have
to enter a subsystem to use it?
10. If you have to enter a subsystem how good is it?
11. support for 8087, support for systems without 8087s
12. large memory model supported?
13. reasonable access to assembler routines when necessary (relinking the
whole runtime system with the routine and then accessing it through
a jump table is not my idea of reasonable).
14. known bugs?
15. char array elements legal as var parameters? is 'x' a char array?
and, of course, any other comments you might wish to tender.
Thanks in advance!tsc2597@acf4.UUCP (Sam Chin) (02/14/85)
Here are some comments with regard to the Logitech Modula II implementation for the IBM PC. I wrote a small virtual memory, concurrent operating system for a MS-DOS 8086 based machine in it. > 1. price, availability etc. We bought about 20 copies for an operating systems class and the price came down to about $150 per copy. You can negotiate with Logitech for bulk purchase If you want to preview it, Springer Verlag is handling their marketing and you may be able to preview it at their offices. > 2. available utilities (debugger?) They have a post mortem source level debugger which is very good. That is whenever the program encounters a run time error it dumps the entire image to disk. You can then see where it crashed and examine variables at the current or higher level scopes. Its main failing is that you cannot step through a program or set break points (like dbx). It uses its own linker. > 3. level of company support The person who wrote the compiler is in Sweden. The people here are quite proficient technically but were unable to help me in details on rewriting their run time system for my machine (which is not an IBM PC) > 4. compatibility/extensions etc. I believe that the compiler was ported from Writh's implementation on the Lilith so it is very standard. It has complete facilities to handle the low level operations on machines which use Intel chips (8088, 8086, 8259 etc) The compiler itself runs on any 8086 based machine with MS-DOS. If however you use any of the process management and interrupt routines (such as IOTRANSFER, NEWPROCESS etc) you will have to rewrite the run time system. They provide the MASM source for it and I was successful in rewriting it. It seems that they have a new version which does not need you to run it on the run time system but I have not seen it. They have a multitute of facilites to do low level stuff (set registers, software interupts, inline code etc) and provide examples on how to write interrupt routines for the IBM PC serial port. All of the libraries in Wirth's "Programming in Modula 2" are provided (even process synchronization with send/wait) with the exception of the graphics library which he describes. Logitech also sells a VAX version of the compiler which I use. My typical development cycle involved compiling the code on the VAX before porting the source to the PC. The compilers (VAX vs PC) were written by different people/groups and are not completely compatible but transporting source is not difficult. > 5. memory, disk requirements The version I use requires 192K and 2 360K drives. It is very difficult to work with 2 360K drives because of the size of the compiler and the libraries. You will have to do a lot of disk swapping if you have that minimum configuration and a hard disk is strongly reccomended for serious work. I use 2 8" drives with a total of 2.4 MB and that is fine. > 6. speed of compiler Very very slow 4 pass compiler. Has poor error diagnostics (looks like they used a primitive recursive descent compiler) and the moment you hit an error on one pass it exits! Most decent compilers have some form of error recovery which allows the parse to continue (most people wont mind this unless you write compilers - like me) You will need at least a 512K RAM disk to hold everything. 384K for just the compiler. I use such a configuration and it is still slow. Doesn't speed up by much on an AT either (compared to a 10Mhz 8086) > 7. speed of code produced Doesn't seem bad. But I cannot really comment without disassembling it. I havent run any benchmarks > 8. native code or m-code? Native 8086 code. The run time system merely holds the routines needed to load the rest of the program and handle processes. It seems that they have a new version which does not need the run time system. > 9. Is the compiler just another DOS program or do you have to enter a subsystem to use it? Since the compiler itself is a modula program, you have to load the run time system first eg. A>M2 comp <prog name> >10. If you have to enter a subsystem how good is it? Its not really a subsystem. All it does is load the image into memory and execute it. It also loads the routines which are required for process and interrupt handling (through the 8259). Interestingly it seems like the only way to interface assembler language routines is to extend the run time system. >11. support for 8087, support for systems without 8087s They claim it works but I never tried it (actually for lack of a 10Mhz 8087) >12. large memory model supported? Yes and that is the only model which is actually quite a disaster because programs written using the small model are half the size and run twice as fast. Most of the time you don't need 1MB addressability and addressing within a segment is super efficient. >13. reasonable access to assembler routines when necessary (relinking the whole runtime system with the routine and then accessing it through a jump table is not my idea of reasonable). If that is your criteria, definately no. If you get good at modula though, you really don't need a line of assembly language. My evidence is that I wrote a fairly complete virtual memory, multitasking os for my machine without a line of assembler. I would like an assembler interface though because it seems more natural to write some things in assembler. There is a facility to insert inline code. 14. known bugs? Non serious that I found. 15. char array elements legal as var parameters? is 'x' a char array? I think I have passed a char array as a reference parameter. 'x' as a constant is not a char array (I think). In summary, the Logitech implementation is certainly a usable and correct implementation of Modula 2 and is the only choice if you want to do serious work. I have heard horror stories of the version from Modula Corp. and volitions runs on the P-system (if the company isn't already bankrupt). The compiler is crummy but usable (so are 80% of PC compilers). I would suggest that anyone embarking on a serious project in modula on the PC, have access to a VAX to do most of your development prior to moving to the PC. Sam Chin (tsc2597@nyu-acf4)
tsc2597@acf4.UUCP (Sam Chin) (02/20/85)
Here are some comments with regard to the Logitech Modula II implementation for the IBM PC. I wrote a small virtual memory, concurrent operating system for a MS-DOS 8086 based machine in it. > 1. price, availability etc. We bought about 20 copies for an operating systems class and the price came down to about $150 per copy. You can negotiate with Logitech for bulk purchase If you want to preview it, Springer Verlag is handling their marketing and you may be able to preview it at their offices. > 2. available utilities (debugger?) They have a post mortem source level debugger which is very good. That is whenever the program encounters a run time error it dumps the entire image to disk. You can then see where it crashed and examine variables at the current or higher level scopes. Its main failing is that you cannot step through a program or set break points (like dbx). It uses its own linker. > 3. level of company support The person who wrote the compiler is in Switzerland. The people here are quite proficient technically but were unable to help me in details on rewriting their run time system for my machine (which is not an IBM PC) > 4. compatibility/extensions etc. I believe that the compiler was ported from Writh's implementation on the Lilith so it is very standard. It has complete facilities to handle the low level operations on machines which use Intel chips (8088, 8086, 8259 etc) The compiler itself runs on any 8086 based machine with MS-DOS. If however you use any of the process management and interrupt routines (such as IOTRANSFER, NEWPROCESS etc) you will have to rewrite the run time system. They provide the MASM source for it and I was successful in rewriting it. It seems that they have a new version which does not need you to run it on the run time system but I have not seen it. They have a multitute of facilites to do low level stuff (set registers, software interupts, inline code etc) and provide examples on how to write interrupt routines for the IBM PC serial port. All of the libraries in Wirth's "Programming in Modula 2" are provided (even process synchronization with send/wait) with the exception of the graphics library which he describes. Logitech also sells a VAX version of the compiler which I use. My typical development cycle involved compiling the code on the VAX before porting the source to the PC. The compilers (VAX vs PC) were written by different people/groups and are not completely compatible but transporting source is not difficult. > 5. memory, disk requirements The version I use requires 192K and 2 360K drives. It is very difficult to work with 2 360K drives because of the size of the compiler and the libraries. You will have to do a lot of disk swapping if you have that minimum configuration and a hard disk is strongly reccomended for serious work. I use 2 8" drives with a total of 2.4 MB and that is fine. > 6. speed of compiler Very very slow 4 pass compiler. Has poor error diagnostics (looks like they used a primitive recursive descent compiler) and the moment you hit an error on one pass it exits! Most decent compilers have some form of error recovery which allows the parse to continue (most people wont mind this unless you write compilers - like me) You will need at least a 512K RAM disk to hold everything. 384K for just the compiler. I use such a configuration and it is still slow. Doesn't speed up by much on an AT either (compared to a 10Mhz 8086) > 7. speed of code produced Doesn't seem bad. But I cannot really comment without disassembling it. I havent run any benchmarks > 8. native code or m-code? Native 8086 code. The run time system merely holds the routines needed to load the rest of the program and handle processes. It seems that they have a new version which does not need the run time system. > 9. Is the compiler just another DOS program or do you have to enter a subsystem to use it? Since the compiler itself is a modula program, you have to load the run time system first eg. A>M2 comp <prog name> >10. If you have to enter a subsystem how good is it? Its not really a subsystem. All it does is load the image into memory and execute it. It also loads the routines which are required for process and interrupt handling (through the 8259). Interestingly it seems like the only way to interface assembler language routines is to extend the run time system. >11. support for 8087, support for systems without 8087s They claim it works but I never tried it (actually for lack of a 10Mhz 8087) >12. large memory model supported? Yes and that is the only model which is actually quite a disaster because programs written using the small model are half the size and run twice as fast. Most of the time you don't need 1MB addressability and addressing within a segment is super efficient. >13. reasonable access to assembler routines when necessary (relinking the whole runtime system with the routine and then accessing it through a jump table is not my idea of reasonable). If that is your criteria, definately no. If you get good at modula though, you really don't need a line of assembly language. My evidence is that I wrote a fairly complete virtual memory, multitasking os for my machine without a line of assembler. I would like an assembler interface though because it seems more natural to write some things in assembler. There is a facility to insert inline code. 14. known bugs? Non serious that I found. 15. char array elements legal as var parameters? is 'x' a char array? I think I have passed a char array as a reference parameter. 'x' as a constant is not a char array (I think). In summary, the Logitech implementation is certainly a usable and correct implementation of Modula 2 and is the only choice if you want to do serious work. I have heard horror stories of the version from Modula Corp. and volitions runs on the P-system (if the company isn't already bankrupt). The compiler is crummy but usable (so are 80% of PC compilers). I would suggest that anyone embarking on a serious project in modula on the PC, have access to a VAX to do most of your development prior to moving to the PC. Sam Chin (tsc2597@nyu-acf4)