Perforce Fortran sync successful
Marty Stanquist
Perforce using the following "overlay mapping" view:
View:
//depot/openwatcom/... //YOURNAME_YOURMACHINE_YOUROS/...
+//depot/ow_devel/fortran.F95.dev/... //YOURNAME_YOURMACHINE_YOUROS/...
+//depot/ow_devel/fortran.F03.dev/... //YOURNAME_YOURMACHINE_YOUROS/...
Perforce describes this feature in the P4 User Guide p4guide.pdf, Chapter 2
Overlay Mappings, p.28.
After setting my Perforce environmental variables, I entered the following
commands into a dos box:
cd c:\SwDev\OW <<my root directory>>
p4 client << add view using text editor, save file, close editor>>
p4 sync << download the files>>
This downloaded the "openwatcom" and Fortran code bases into my root
directory c:\SwDev\OW. The Fortran files were loaded into the \bld
directory as shown below (just showing a cut/paste from dig to idebatch).
With all the files now at hand, I'll try building the Fortran directories
separately to see what happens.
C:\SwDev\OW>dir bld
Volume in drive C is HP
Volume Serial Number is 884B-22E3
Directory of C:\SwDev\OW\bld
06/22/2011 07:43 PM <DIR> dig
06/22/2011 07:43 PM <DIR> dip
06/22/2011 07:43 PM <DIR> dmpobj
06/22/2011 07:43 PM <DIR> dwarf
06/22/2011 07:43 PM <DIR> editdll
06/22/2011 07:43 PM <DIR> emu
06/22/2011 07:43 PM <DIR> emu86
06/22/2011 07:43 PM <DIR> exedump
06/22/2011 07:42 PM <DIR> F03 <<<<
06/22/2011 07:28 PM <DIR> F03f77lib <<<<
06/22/2011 07:44 PM <DIR> f77 <<<<
06/22/2011 07:33 PM <DIR> F95 <<<<
06/22/2011 07:33 PM <DIR> F95.current <<<<
06/22/2011 07:44 PM <DIR> fe_misc
06/22/2011 07:44 PM <DIR> fileext
06/22/2011 07:44 PM <DIR> fmedit
06/22/2011 07:44 PM <DIR> graphlib
06/22/2011 07:44 PM <DIR> gui
06/22/2011 07:44 PM <DIR> hcdos
06/22/2011 07:44 PM <DIR> hdr
06/22/2011 07:44 PM <DIR> help
06/22/2011 07:44 PM <DIR> helpcomp
06/22/2011 07:44 PM <DIR> idebatch
Peter C. Chapin
> This downloaded the "openwatcom" and Fortran code bases into my root
> directory c:\SwDev\OW. The Fortran files were loaded into the \bld
> directory as shown below (just showing a cut/paste from dig to
> idebatch). With all the files now at hand, I'll try building the Fortran
> directories separately to see what happens.
You should probably do a full build of the trunk to make sure all
supporting tools and libraries are in place. Then you can try issuing
wmake commands in the appropriate subdirectories from the branch and see
how it goes.
Peter
Marty Stanquist
"Peter C. Chapin" wrote in message news:iu2oj1$puf$1...@www.openwatcom.org...
-------
Thanks. Do you initiate the full build by doing:
cd /SwDev/OW <<root dir>>
build.cmd <<builds the builder>>
builder build <<builds OW>>
If correct, does this build a debug version of the project tree?
Marty
Hans-Bernhard Bröker
> Thanks. Do you initiate the full build by doing:
>
> cd /SwDev/OW <<root dir>>
> build.cmd <<builds the builder>>
No. build.cmd builds the whole thing.
> builder build <<builds OW>>
"build.cmd" already did that.
> If correct, does this build a debug version of the project tree?
Only if you asked for it in your environment setup. But you typically
don't want a full debug build anyway. Build debug versions of the
things your actually looking at, selectively, instead.
Marty Stanquist
Compiling Open Watcom - Procedure on Windows platforms.
http://vortex.cis.vtc.edu/pcc/OW-compiling.html
on the OW contributor resources web page. It might be a broken link.
I'll try a full release build to initialize everything, then a debug build
just for Fortran.
Marty
"Hans-Bernhard Bröker" wrote in message
news:iu34ja$vn6$1...@www.openwatcom.org...
Peter C. Chapin
> Thanks for the clarification. I had trouble accessing the document:
>
> Compiling Open Watcom - Procedure on Windows platforms.
> http://vortex.cis.vtc.edu/pcc/OW-compiling.html
>
> on the OW contributor resources web page. It might be a broken link.
Yes. The correct URL is
http://web.vtc.edu/users/pcc09070/OW/compiling.html
I'll fix the Wiki; thanks for pointing it out. That document is a bit
dated but it should be mostly correct.
You don't want to try a full debug build of everything. It doesn't really
work properly right now (it never has as far as I know).
Peter
Marty Stanquist
build with just one minor error. Near the end of the build I get a dos box
64-bit compatibility error message for c:\SwDev\OW\docs\gml\dos\wgml.exe
just after the banner message "================== 10:15:21
C:\SwDev\OW\bld\browser\nt386 ===================". I was running build.cmd
with the Windows-NT compatibility mode set and the build appears to have run
to a normal completion. I am running an Athlon X2 machine on Windows 7 x64.
After running wmake in the various c:\SwDev\OW\bld\Fxx\wfc\nt386.386
directories, it looks like F95 and F95.current are not presently hooked into
the build sequence since they are missing:
text files:
asmops.gh, asmopsd.gh, exever.grc, msg.gh
and executable and object files:
mkopcod1.exe, mkopcod1.obj, mkopcode.exe, mkopcode.obj
F03 as well as f77, C, and C++ do have these files which are built from code
in directory c:\SwDev\OW\bld\wasm. F03\wfc blows up very early in the wmake
and locks up the dos box after about 4 or 5 statements. I examined the *.gh
and *.grc files and the text looks normal (although possibly not correct).
This is at least a starting point.
Marty
"Peter C. Chapin" wrote in message news:iu4hli$nph$1...@www.openwatcom.org...
Marty Stanquist
the msg.gh target was processed by awk previously and now by vi. The vi
command is not completing correctly and is causing the dos box to lock up. I
tried doing a <esc>:q! in vi but it does not exit. See the excerpts from a
log taken of wmake run in the c:\SwDev\OW\bld\F03\wfc\nt386.386 directory.
Marty
from c:\SwDev\OW\bld\f77\wfc\master.mif
msg.gh : $(wasm_dir)/h/asmshare.msg
$(awk) -v base=MSG_RC_BASE -f $(misc_dir)/makemsg.awk $[@ > $^@
from c:\SwDev\OW\bld\F03\wfc\master.mif
msg.gh : $(wasm_dir)/h/asmshare.msg
$(vi) -s $(wasm_dir)/h/makemsg.vi -p "$^@ MSG_RC_BASE" $[@
----------
cd c:\SwDev\OW\bld\F03\wfc\nt386.386
wmake /a /sn > wmake.log 2>&1
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
set include=
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcod1.c -fpi -ox -w8 -fe=.\mkopcod1.exe
.\mkopcod1.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmops.gh
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcode.c -fpi -ox -w8 -fe=.\mkopcode.exe
.\mkopcode.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmopsd.gh
vi -q -d -i -s c:\SwDev\OW\bld\wasm/h/makemsg.vi -p "msg.gh MSG_RC_BASE"
c:\SwDev\OW\bld\wasm\h\asmshare.msg
"Marty Stanquist" wrote in message news:iu5fm8$p7m$1...@www.openwatcom.org...
Hans-Bernhard Bröker
> It looks like there was a change in master.mif going from f77 to F03
> where the msg.gh target was processed by awk previously and now by vi.
Actually you have that backwards. This kind of text processing jobs
_used_ to be done by a (special version) of vi in the build process,
called "bvi". Jiri changed that from vi to more batch-operation
oriented tools like sed and awk by change 33678 in 2008 --- quite a
while after the F03 branch was forked off 2005. This change was never
integrated over into the F03 branch, so you still have $(vi) stuff in there.
> vi -q -d -i -s c:\SwDev\OW\bld\wasm/h/makemsg.vi -p "msg.gh MSG_RC_BASE"
> c:\SwDev\OW\bld\wasm\h\asmshare.msg
I doubt the $(vi) in that makefile was supposed to expand to plain 'vi'
there. That should probably have been 'bvi' instead.
Peter C. Chapin
> Thanks, that made a big difference. I've been able to get through the
> full build with just one minor error. Near the end of the build I get a
> dos box 64-bit compatibility error message for
> c:\SwDev\OW\docs\gml\dos\wgml.exe just after the banner message
> "================== 10:15:21 C:\SwDev\OW\bld\browser\nt386
> ===================". I was running build.cmd with the Windows-NT
> compatibility mode set and the build appears to have run to a normal
> completion. I am running an Athlon X2 machine on Windows 7 x64.
That's "normal." The source code for one of our documentation building
tools has been lost to time and we only have a 16 bit executable for it.
Unfortunately such executables don't run on 64 bit Windows. There is work
in progress to reconstruct the source of the tool in question so that we
can compile 32 bit versions of those tools, but that work is not
finished. In the mean time you'll have to either a) live without
documentation or b) do your build on a 32 bit system ... maybe inside a
32 bit VM.
> After running wmake in the various c:\SwDev\OW\bld\Fxx\wfc\nt386.386
> directories, it looks like F95 and F95.current are not presently hooked
> into the build sequence since they are missing:
The normal build of the trunk won't process those branch folders. Is that
what you mean?
Peter
Peter C. Chapin
> from c:\SwDev\OW\bld\f77\wfc\master.mif
>
> msg.gh : $(wasm_dir)/h/asmshare.msg
> $(awk) -v base=MSG_RC_BASE -f $(misc_dir)/makemsg.awk $[@ > $^@
>
> from c:\SwDev\OW\bld\F03\wfc\master.mif
>
> msg.gh : $(wasm_dir)/h/asmshare.msg
> $(vi) -s $(wasm_dir)/h/makemsg.vi -p "$^@ MSG_RC_BASE" $[@
Sounds like the first order of business is to change the use $(vi) into a
use of $(awk).
Peter
Marty Stanquist
try building them separately on Win-NT running inside Qemu, then just set
env variable DOC_BUILD=0 for the main build that I'll run outright on
Win-7x64. As for awk, I'll put Jiri's fix (below) into the makefile and will
give it a try.
msg.gh : $(wasm_dir)/h/asmshare.msg
$(awk) -v base=MSG_RC_BASE -f $(misc_dir)/makemsg.awk $[@ > $^@
Marty
"Peter C. Chapin" wrote in message news:iu778r$3l9$1...@www.openwatcom.org...
Paul S. Person
<PCh...@vtc.vsc.edu> wrote:
>On Sat, 25 Jun 2011 15:16:16 -0500, Marty Stanquist wrote:
>
>> Thanks, that made a big difference. I've been able to get through the
>> full build with just one minor error. Near the end of the build I get a
>> dos box 64-bit compatibility error message for
>> c:\SwDev\OW\docs\gml\dos\wgml.exe just after the banner message
>> "================== 10:15:21 C:\SwDev\OW\bld\browser\nt386
>> ===================". I was running build.cmd with the Windows-NT
>> compatibility mode set and the build appears to have run to a normal
>> completion. I am running an Athlon X2 machine on Windows 7 x64.
>
>That's "normal." The source code for one of our documentation building
>tools has been lost to time and we only have a 16 bit executable for it.
>Unfortunately such executables don't run on 64 bit Windows. There is work
>in progress to reconstruct the source of the tool in question so that we
>can compile 32 bit versions of those tools, but that work is not
>finished. In the mean time you'll have to either a) live without
>documentation or b) do your build on a 32 bit system ... maybe inside a
>32 bit VM.
IIRC, someone managed to get DOSBox to run wgml on 64-bit Windows. I
think he had to hack the source a bit, though. DOSBox is, of course, a
32-bit program that does its own emulation.
--
"'If God foreknew that this would happen,
it will happen.'"
Uwe Schmelich
Don't know if someone else did it too, however I tried it a year ago with
dosbox0.74. Had to make some (small) changes to dosbox regarding error
code return (originally 0) and splash screen removal (it was a nuisance).
I'm not sure if the return code problem was because dosbox was designed
mostly for games or for a "business" reason. The guys who wrote dosbox
don't seem to like the use of dosbox as a full emulator for business
purposes (that's my interpretation of some comments regarding the splash
screen), however cannot really do something about it because of GPL
freedom.
It worked in principle, but it took sooome time to compile the wgml stuff.
If I remember correctly it was at least a factor of 3 or 4 to a native
compile under 32 bit.
It was necessary to rework some of the makefiles a bit too, because I didn't
found a way to start dosbox on behalf of windows error 216. This would be
the cleanest way I think to transparently support the emulation. If windows
detects the 16 bit exe it should call a replacement 32 bit dosbox hull exe
(or a shell script). Some support seems to exist in Win7 for special things
like setup.exe but nothing worked for me with this dosbox setup. I hadn't
that much time so I left it alone.
One other problem surfaced. There are 16 bit tests for the 16 bit compiler.
To make it fully work (all of OW) you would have to support the emulation
for them too. This may require some bigger changes to the makefiles, if
transparent emulation isn't possible.
Uwe
Marty Stanquist
the "-we" compiler flag. But all the issues have been minor, mainly missing
prototypes and type mismatches. I hope to get it built sometime this week.
Marty
c:\SwDev\OW\bld\F03\wfc\nt386.386>wmake /a
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\O
W\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcod1.c -fpi -ox -w8 -fe=.\mkopcod1.exe
.\mkopcod1.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmops.gh
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\O
W\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcode.c -fpi -ox -w8 -fe=.\mkopcode.exe
.\mkopcode.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmopsd.gh
awk -v base=MSG_RC_BASE -f c:\SwDev\OW\bld\sdk\misc/makemsg.awk
c:\SwDev
\OW\bld\wasm\h\asmshare.msg > msg.gh
c++ argchk.obj
cc cbsize.obj
c++ chain.obj
c++ fmemmgr.obj
cc mkname.obj
c++ rstutils.obj
cc subscr.obj
cc substr.obj
c++ types.obj
cc errgrp.obj
cc blips.obj
cc cnvd2s.obj
c++ filescan.obj
c++ sdcio.obj
cc tcmplx.obj
c++ poscc.obj
c++ posdel.obj
c++ posdat.obj
c++ poserr.obj
c++ posflush.obj
c++ posget.obj
c++ posopen.obj
c++ posput.obj
c++ posrew.obj
c++ posseek.obj
c++ aentry.obj
c++ allocate.obj
c++ arglist.obj
c++ arutls.obj
cc hash.obj
cc cfmttab.obj
cc cftable.obj
c++ cle.obj
cc cmsgproc.obj
cc comdump.obj
cc comio.obj
cc common.obj
cc compprog.obj
cc compstmt.obj
cc convert.obj
cc cpmisc.obj
cc cpsubpgm.obj
..\c\cpsubpgm.c(87): Warning! W131: No prototype found for function
'CkSubEnd'
..\c\cpsubpgm.c(93): Warning! W131: No prototype found for function
'StartProg'
..\c\cpsubpgm.c(202): Warning! W131: No prototype found for function
'ParmList'
..\c\cpsubpgm.c(317): Warning! W131: No prototype found for function
'CkRemBlock
'
..\c\cpsubpgm.c(488): Warning! W131: No prototype found for function
'InitParms'
..\c\cpsubpgm.c(506): Warning! W131: No prototype found for function
'DoWarps'
Error(E42): Last command making (cpsubpgm.obj) returned a bad status
Error(E02): Make execution terminated
c:\SwDev\OW\bld\F03\wfc\nt386.386>
Bartosz Polednia
> I've been able to get all the ow_devel Fortran files downloaded from
> Perforce using the following "overlay mapping" view:
Marty,
As I see you are making many changes to F03 branch.
I have done some source cleaning to compiler from main branch after F03
was forked. Could you check if our job is not duplicated ?
Bartosz.
Marty Stanquist
Here is my thinking in moving forward. The cleanup in the main branch is
very important and should continue. F95 and F03 are unknowns at this point
since they currently do not build and have not yet been evaluated. I think a
lot can be learned from F95 and F03 by making only the minimal changes
needed for the build and evaluation tests. This is what I am currently
doing. In moving forward, we should probably continue working on the main
branch until we are satisfied that it is refined enough to be forked again.
Starting with a more recent fork and our test results from F95 and F03, we
could put a team together to begin working on a new compiler for F2006 or
F2008. This would be a very nice enhancement for OW 2.0.
Marty
"Bartosz Polednia" wrote in message news:iuhgvp$bbr$1...@www.openwatcom.org...
Peter C. Chapin
> Here is my thinking in moving forward. The cleanup in the main branch is
> very important and should continue. F95 and F03 are unknowns at this
> point since they currently do not build and have not yet been evaluated.
> I think a lot can be learned from F95 and F03 by making only the minimal
> changes needed for the build and evaluation tests. This is what I am
> currently doing. In moving forward, we should probably continue working
> on the main branch until we are satisfied that it is refined enough to
> be forked again. Starting with a more recent fork and our test results
> from F95 and F03, we could put a team together to begin working on a new
> compiler for F2006 or F2008. This would be a very nice enhancement for
> OW 2.0.
So to be clear you are suggesting that the current F95 and F03 branches
ultimately be abandoned and replaced with a new, single branch for, say,
Fortran 2008. Yes?
Peter
Marty Stanquist
fork of a further refined f77. The f77 branch is probably the best starting
point for Fortran 2008 due to all the recent bug fixes. I think F03 will be
useful as a prototype for algorithm and compatibility test development as we
move forward with the new compiler.
Marty
"Peter C. Chapin" wrote in message news:iuneg3$pf1$4...@www.openwatcom.org...
Peter C. Chapin
> Yes. I'd like to see us transition to a single Fortran branch based on a
> fork of a further refined f77. The f77 branch is probably the best
> starting point for Fortran 2008 due to all the recent bug fixes. I think
> F03 will be useful as a prototype for algorithm and compatibility test
> development as we move forward with the new compiler.
That sounds fine with me. Have you had a chance to closely examine what's
in the F03 branch? It might not be very different than the original F77
code base from which it came. I'm not sure how much forward progress has
been made on Fortran compiler updates.
Peter
Marty Stanquist
after I get it built. All the build issues so far have been minor and about
2/3 of the files are now compiling without warnings or errors.
Marty
"Peter C. Chapin" wrote in message news:iuo614$74k$3...@www.openwatcom.org...
Bartosz Polednia
Most of my changes was just making prototypes and moving them to headers
and polishing these headers.
IMHO you are dupicating my work but I do not follow all your changes
so maybe I am missing sth. in the horizon.
Bartosz.
Marty Stanquist
project, running some tests, and reviewing the code. The changes I'm making
are only to correct build errors. Since F03 is missing critical bug fixes,
it is not an optimal starting point for a new design. The main f77 branch is
a better candidate for this. After evaluating F03, I anticipate using it as
a prototype for testing out new parsing algorithms and compiler tests. But
once we have the new compiler up and running, the F95 and F03 branches can
then be archived and removed. In moving forward, we should spend time
updating the main f77 branch, as you are now doing, with any remaining
cleanup and bug fixes. This will allow us to then freeze the design and fork
it for the new project. With this complete, we can all begin working on the
new compiler in a single branch.
Marty
"Bartosz Polednia" wrote in message news:iup6fl$pit$1...@www.openwatcom.org...
Marty Stanquist
freenode) after 9pm and again before 9am CST US on weekdays, periodically on
weekends. Hope to see you there.
Marty
Olafur Gunnlaugsson
> Yes. I'd like to see us transition to a single Fortran branch based on a
> fork of a further refined f77. The f77 branch is probably the best
> starting point for Fortran 2008 due to all the recent bug fixes. I think
> F03 will be useful as a prototype for algorithm and compatibility test
> development as we move forward with the new compiler.
>
> Marty
That sounds excellent but given that work on Fortran 2011/12 is well
under-way (ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1854.pdf) and that
is likely to be a formal standard before work finishes on the Watcom
compiler would it not be right to keep one eye on the TR 29113 rather
than focus solely on 2008 just so not as to have to duplicate any work
in the future?
Marty Stanquist
significant update (see introduction page v, Further Interoperability of
Fortran with C). With Fortran evolving as it is, we'll have to choose a
compiler architecture that is easily extendable, yet preserves all the
progress made so far with f77. Since we'll be getting feedback from legacy
maintainers (Fortran 77, 90, and 95) in addition to leading edge developers
(Fortran 2003 and beyond), we'll need to have a good test plan in place to
ensure that we are compliant with all the standards. I am aware of test
suites only for Fortran 77 and 95 (see links below). Are you aware of any
others, especially for Fortran 2003 and above? We'll probably have to create
one ourselves.
http://www.itl.nist.gov/div897/ctg/fortran_form.htm
(fcvs21.tar.Z)
http://www.fortran-2000.com/ArnaudRecipes/fcvs21_f95.html
(fcvs21_f95.tar.bz2)
Marty
"Olafur Gunnlaugsson" wrote in message
news:iutekf$d2p$1...@www.openwatcom.org...
Lynn McGuire
> Here's what the F03 build looks like so far. It's going a bit slow due to the "-we" compiler flag. But all the issues have been
> minor, mainly missing prototypes and type mismatches. I hope to get it built sometime this week.
>
> Marty
>
> c:\SwDev\OW\bld\F03\wfc\nt386.386>wmake /a
Is this going to replace the existing wfl386.exe and
wfc386.exe ?
Thanks,
Lynn
Marty Stanquist
projects will compile unmodified on the new compiler.
Marty
"Lynn McGuire" wrote in message news:iuvdfa$jot$1...@www.openwatcom.org...
Peter C. Chapin
> Yes, this will be the new wfl386.exe and wfc386.exe. Legacy Fortran 77
> projects will compile unmodified on the new compiler.
Probably if I knew more about Fortran I could answer this myself...
To ensure compatibility with FORTRAN77 code will it be necessary to use a
special command line switch to activate support for the new language
features? I'm concerned about legacy code bases that might break in the
presence of features they are not expecting.
Peter
Marty Stanquist
will help ensure Fortran 77 compatibility. First, we should make sure that
all Fortran 77 processing is handled by the current Fortran 77 action
routines, which should be left unmodified in the new design. When processing
Fortran 90 and beyond statements, we should try to use as much of the
existing code as possible, but when enhancements are needed, a new
subroutine should be called, leaving the Fortran 77 routine as is. Second,
for users wanting to limit the compilation to the Fortran 77 standard, or to
allow depreciated statements in newer code, command line switches should be
used to modify the behavior of the parser. The new compiler will also need
to support the existing command line switches to ensure that legacy
makefiles run unmodified.
Marty
"Peter C. Chapin" wrote in message news:iv1nku$736$1...@www.openwatcom.org...
Marty Stanquist
errors or warnings. I'm apparently missing a library (possibly the Fortran
runtime) due to all the linker errors (4 pages worth). But I'm looking at
this now.
Marty
c:\SwDev\OW\bld\F03\wfc\nt386.386>wmake /a > wmake.log 2>&1
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcod1.c -fpi -ox -w8 -fe=.\mkopcod1.exe
.\mkopcod1.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmops.gh
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
cc csatend.obj
cc cscycle.obj
cc csexit.obj
cc csgoto.obj
cc csguess.obj
cc csif.obj
cc csloops.obj
cc csquit.obj
cc csremblk.obj
cc csselect.obj
cc csutls.obj
cc data.obj
cc detach.obj
cc downscan.obj
cc dsname.obj
cc equiv.obj
cc error.obj
cc external.obj
cc fmterr.obj
cc fmtinit.obj
c++ frl.obj
cc iflookup.obj
cc ifused.obj
c++ impltab.obj
cc include.obj
c++ insert.obj
cc intrnsc.obj
cc ioiolist.obj
cc iokwlist.obj
cc ioperm.obj
c++ ioprockw.obj
cc iostmts.obj
cc ioutls.obj
cc kwlist.obj
cc kwlook.obj
cc kwlookup.obj
cc lex.obj
cc namelist.obj
cc oprtab.obj
cc parmcode.obj
cc parmeter.obj
cc proctbl.obj
c++ recog.obj
cc rstalloc.obj
cc rstconst.obj
cc rstdump.obj
cc rstglist.obj
cc rstlit.obj
cc rstnlist.obj
cc rstsrch.obj
cc rststmt.obj
cc rststruc.obj
cc save.obj
cc scan.obj
cc setopn.obj
cc showopts.obj
c++ stmtfunc.obj
cc stmtno.obj
cc stresolv.obj
cc struct.obj
c++ symtab.obj
cc union.obj
c++ upscan.obj
cc usconst.obj
cc usfold.obj
cc usother.obj
c++ utility.obj
c++ volatile.obj
cc blderr.obj
cc chinese.obj
cc csetinfo.obj
cc dbcsutil.obj
cc english.obj
cc errrtns.obj
cc errutil.obj
cc fmtboth.obj
cc fmtcnvt.obj
cc fmtscan.obj
cc hexcnv.obj
cc japanese.obj
cc korean.obj
cc lexcmp.obj
cc errrsrc.obj
cc asgnop.obj
cc binops.obj
cc cgformat.obj
cc cgmagic.obj
cc cptraps.obj
cc csdep.obj
cc docle.obj
cc emit.obj
cc exprutil.obj
cc fltused.obj
c++ galloc.obj
cc gcnvt.obj
cc gdata.obj
cc gdbginfo.obj
cc gdo.obj
cc gio.obj
cc global.obj
cc gsfunc.obj
cc gstring.obj
c++ gsublist.obj
c++ gsubprog.obj
cc gsubscr.obj
cc gtypes.obj
cc ifdump.obj
cc libsupp.obj
cc logops.obj
cc relops.obj
cc sdcline.obj
cc stkops.obj
cc tdinit.obj
cc upcat.obj
cc _matherr.obj
cc brseinfo.obj
cc browscli.obj
cc writ_elf.obj
cc btraps.obj
cc intarith.obj
cc sdfile.obj
cc errinit.obj
cc fcalloc.obj
cc fcbinary.obj
cc fcbits.obj
cc fccmplx.obj
cc fccnvt.obj
cc fcdbg.obj
cc fcdo.obj
cc fcflow.obj
cc fcformat.obj
cc fcio.obj
cc fcjmptab.obj
cc fclogic.obj
cc fcmisc.obj
cc fcrelops.obj
cc fcsel.obj
cc fcstring.obj
cc fcstruct.obj
cc fcsubscr.obj
cc fcsyms.obj
cc fctemp.obj
cc auxlook.obj
cc forcstat.obj
cc gsegs.obj
cc objutil.obj
c++ boot77.obj
cc declare.obj
cc fmacros.obj
cc fmtemit.obj
cc implicit.obj
cc inout.obj
cc option.obj
cc proclist.obj
c++ rstmgr.obj
cc fieldops.obj
cc gflow.obj
cc gsubstr.obj
cc initopt.obj
c++ mainline.obj
cc regs.obj
cc wf77aux.obj
cc asmalloc.obj
cc asmmsg.obj
cc asmins.obj
cc asmscan.obj
cc asmline.obj
cc asmsym.obj
cc tbyte.obj
cc asmlabel.obj
cc asmfixup.obj
cc asmmatch.obj
cc asmdata.obj
cc asmjump.obj
cc asmexpnd.obj
cc asmeval.obj
cc fccall.obj
cc fcdata.obj
cc fcfield.obj
cc fcgmain.obj
cc fcrtns.obj
cc inline.obj
cc fcifns.obj
cc fcstack.obj
cc wf77info.obj
cc fctypes.obj
cc dumpnode.obj
bwrc -q -bt=windows -Ic:\SwDev\OW\bld\watcom\h -zk0 -r -I"../../h" -I"c:\SwDev\OW\bld\wasm/h"
-I"c:\SwDev\OW\bld\comp_cfg/h" -I"c:\SwDev\OW\bld\fe_misc/h"
..\c\errmsg.rc -fo=errmsg.res
%create wfc386.lnk
wlink op q debug dwarf option symfile sys nt op stack=1024k commit
stack=32k op map @wfc386.lnk
Warning! W1027: file
c:\SwDev\OW\bld\cg/intel/386/nt386/cg386nt.lib(C:\SwDev\OW\bld\cg\c\memmgr.c):
redefinition of MemAlloc_ ignored
Warning! W1027: file
c:\SwDev\OW\bld\cg/intel/386/nt386/cg386nt.lib(C:\SwDev\OW\bld\cg\c\memmgr.c):
redefinition of MemFree_ ignored
Warning! W1027: file
c:\SwDev\OW\bld\cg/intel/386/nt386/cg386nt.lib(C:\SwDev\OW\bld\cg\c\memmgr.c):
redefinition of MemFini_ ignored
Error! E2028: void near Error( int, ... ) is an undefined reference
Error! E2028: void near * near Openf( char near *, int ) is an undefined
reference
Error! E2028: void near Closef( void near * ) is an undefined reference
Error! E2028: void near * near FStdOut is an undefined reference
Error! E2028: void near CheckBlips() is an undefined reference
Error! E2028: void near FSeekRec( void near *, long unsigned, int ) is an
undefined reference
Error! E2028: void near FRewind( void near * ) is an undefined reference
Error! E2028: bool near EOFile( void near * ) is an undefined reference
Error! E2028: int near Errorf( void near * ) is an undefined reference
Error! E2028: char near * near ErrorMsg( void near * ) is an undefined
reference
Error! E2028: void near FSetSysErr( b_file near * ) is an undefined
reference
Error! E2028: void near FSetEof( b_file near * ) is an undefined reference
Error! E2028: void near FSetTrunc( b_file near * ) is an undefined reference
Error! E2028: void near FSetErr( int, b_file near * ) is an undefined
reference
Error! E2028: void near IOOk( b_file near * ) is an undefined reference
Error! E2028: int unsigned near __IOMode( int ) is an undefined reference
Error! E2028: void near __SetIOMode( int, int unsigned ) is an undefined
reference
Error! E2028: int near FSetCC( b_file near *, char, char near * near * ) is
an undefined reference
Error! E2028: void near DownScan() is an undefined reference
Error! E2028: void near Extension( int, ... ) is an undefined reference
Error! E2028: void near InitGlobalSegs() is an undefined reference
Error! E2028: void near InitAuxInfo() is an undefined reference
Error! E2028: void near FiniAuxInfo() is an undefined reference
Error! E2028: void near FreeGlobalSegs() is an undefined reference
Error! E2028: void near InitMacros() is an undefined reference
Error! E2028: void near ComReadFree() is an undefined reference
Error! E2028: void near FiniMacros() is an undefined reference
Error! E2028: void near DoCompile() is an undefined reference
Error! E2028: void near StatProg() is an undefined reference
Error! E2028: void near STPurge() is an undefined reference
Error! E2028: void near CSPurge() is an undefined reference
Error! E2028: void near EqPurge() is an undefined reference
Error! E2028: void near TDPurge() is an undefined reference
Error! E2028: void near FiniMacroProcessor() is an undefined reference
Error! E2028: NameErr_ is an undefined reference
Error! E2028: NamNamErr_ is an undefined reference
Error! E2028: SkipBlanks_ is an undefined reference
Error! E2028: RecNOpn_ is an undefined reference
Error! E2028: RecDiv_ is an undefined reference
Error! E2028: ReqName_ is an undefined reference
Error! E2028: LkCommon_ is an undefined reference
Error! E2028: AdvanceITPtr_ is an undefined reference
Error! E2028: ReqDiv_ is an undefined reference
Error! E2028: LkSym_ is an undefined reference
Error! E2028: IllName_ is an undefined reference
Error! E2028: RecOpenParen_ is an undefined reference
Error! E2028: RecCat_ is an undefined reference
Error! E2028: LkBCommon_ is an undefined reference
Error! E2028: RecComma_ is an undefined reference
Error! E2028: ReqEOS_ is an undefined reference
Error! E2028: OpenSymTab_ is an undefined reference
Error! E2028: InitITPool_ is an undefined reference
Error! E2028: STInit_ is an undefined reference
** goes on for 4 more pages **
Marty Stanquist
to C++. The C compiler allows certain void * assignments that the C++
compiler does not. I'll try converting the C++ files back to C and see if
this cleans up the build. From what I can see, no C++ constructs were used.
Marty
Marty Stanquist
c:\SwDev\OW\bld\F03\wfc\nt386.386>wmake /a > wmake.log 2>&1
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcod1.c -fpi -ox -w8 -fe=.\mkopcod1.exe
.\mkopcod1.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmops.gh
bwcl386 -l=nt -IC:\Watcom\h -Ic:\SwDev\OW\bld\watcom\h -zq -I"c:\SwDev\OW\bld\wasm/h"
c:\SwDev\OW\bld\wasm\mkopcode.c -fpi -ox -w8 -fe=.\mkopcode.exe
.\mkopcode.exe c:\SwDev\OW\bld\wasm/inlnops.tok asmopsd.gh
awk -v base=MSG_RC_BASE -f c:\SwDev\OW\bld\sdk\misc/makemsg.awk
c:\SwDev\OW\bld\wasm\h\asmshare.msg > msg.gh
cc argchk.obj
cc cbsize.obj
cc chain.obj
cc fmemmgr.obj
cc fmeminit.obj
cc mkname.obj
cc rstutils.obj
cc subscr.obj
cc substr.obj
cc types.obj
cc errgrp.obj
cc blips.obj
cc cnvd2s.obj
cc filescan.obj
cc sdcio.obj
cc tcmplx.obj
cc poscc.obj
cc posdel.obj
cc posdat.obj
cc poserr.obj
cc posflush.obj
cc posget.obj
cc posopen.obj
cc posput.obj
cc posrew.obj
cc posseek.obj
cc aentry.obj
cc allocate.obj
cc arglist.obj
cc arutls.obj
cc hash.obj
cc cfmttab.obj
cc cftable.obj
cc cle.obj
cc frl.obj
cc iflookup.obj
cc ifused.obj
cc impltab.obj
cc include.obj
cc insert.obj
cc intrnsc.obj
cc ioiolist.obj
cc iokwlist.obj
cc ioperm.obj
cc ioprockw.obj
cc iostmts.obj
cc ioutls.obj
cc kwlist.obj
cc kwlook.obj
cc kwlookup.obj
cc lex.obj
cc namelist.obj
cc oprtab.obj
cc parmcode.obj
cc parmeter.obj
cc proctbl.obj
cc recog.obj
cc rstalloc.obj
cc rstconst.obj
cc rstdump.obj
cc rstglist.obj
cc rstlit.obj
cc rstnlist.obj
cc rstsrch.obj
cc rststmt.obj
cc rststruc.obj
cc save.obj
cc scan.obj
cc setopn.obj
cc showopts.obj
cc stmtfunc.obj
cc stmtno.obj
cc stresolv.obj
cc struct.obj
cc symtab.obj
cc union.obj
cc upscan.obj
cc usconst.obj
cc usfold.obj
cc usother.obj
cc utility.obj
cc volatile.obj
cc blderr.obj
cc chinese.obj
cc csetinfo.obj
cc dbcsutil.obj
cc english.obj
cc errrtns.obj
cc errutil.obj
cc fmtboth.obj
cc fmtcnvt.obj
cc fmtscan.obj
cc hexcnv.obj
cc japanese.obj
cc korean.obj
cc lexcmp.obj
cc errrsrc.obj
cc asgnop.obj
cc binops.obj
cc cgformat.obj
cc cgmagic.obj
cc cptraps.obj
cc csdep.obj
cc cspawn.obj
cc docle.obj
cc emit.obj
cc exprutil.obj
cc fltused.obj
cc galloc.obj
cc gcnvt.obj
cc gdata.obj
cc gdbginfo.obj
cc gdo.obj
cc gio.obj
cc global.obj
cc gsfunc.obj
cc gstring.obj
cc gsublist.obj
cc gsubprog.obj
cc boot77.obj
cc declare.obj
cc fmacros.obj
cc fmtemit.obj
cc implicit.obj
cc inout.obj
cc option.obj
cc proclist.obj
cc rstmgr.obj
cc fieldops.obj
cc gflow.obj
cc gsubstr.obj
cc initopt.obj
cc mainline.obj
rc exever.res
%create wfc386.lnk
wlink op q debug dwarf option symfile sys nt op stack=1024k commit
stack=32k op map @wfc386.lnk
bwrc -q -k exever.res wfc386.exe
wstrip -q -a -r wfc386.exe . errmsg.res
Marty Stanquist
c:\SwDev\OW\bld\F03\wfc\nt386.386>.\wfc386.exe
Open Watcom Fortran 2003/32 Experimental Compiler Version 0.1 2011/07/09
17:55
:25
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Usage: wfc386 {- or /<option>} <file-spec> {- or /<option>}
*File Management Options*
LISt generate a listing file PRint listing file to printer
TYpe listing file to terminal DIsk listing file to disk
INCList list INCLUDE files ERrorfile generate an error file
INCPath path for INCLUDE files FO name object file
*Diagnostic Options*
EXtensions issue extension messages Reference issue unreferenced
warning
WArnings issue warning messages EXPlicit explicit typing required
DEBug /trace /bounds TRace generate run-time
traceback
BOunds generate bounds checking STack stack checking
*Debugging Options*
D1 line # debugging information D2 full debugging
information
HC Codeview debugging info. HD DWARF debugging
information
HW WATCOM debugging information
*Floating-Point Options*
FPC floating-point calls FPI emulate 80x87
instructions
FPI87 in-line 80x87 instructions FP2 80287 instructions
FP3 80387 instructions FP5 /fp3 optimized for
Pentium
FP6 /fp3 optimized for Pentium Pro
FPR 80x87 reverse compatibility FPD enable Pentium FDIV check
*Optimizations*
OB base pointer optimizations OBP branch prediction
OC no call-ret optimizations OD disable optimizations
OF no stack frame optimizations
OH optimize at expense of compile-time
OI statement functions in-line
OK move register saves into flow graph
OL loop optimizations OL+ loop
optimizations/unrolling
OM math optimizations ON numerical optimizations
OP precision optimizations OR instruction scheduling
OS space optimizations OT time optimizations
ODO DO-variables do not overflow OX /o[b,bp,i,k,l,m,r,t,do]
*Memory Models*
MF flat memory model MS small memory model
MC compact memory model MM medium memory model
ML large memory model
*CPU Targets*
3 assume 80386 processor 4 /3 optimized for 80486
5 /3 optimized for Pentium 6 /3 optimized for Pentium
Pro
*Application Type*
BW default windowed application BM multithread application
BD dynamic link library WINdows generate code for Windows
*Character Set Options*
CHInese Chinese character set Japanese Japanese character set
KOrean Korean character set
*Miscellaneous Options*
SHort INTEGER/LOGICAL size 2/1 XFloat extend float-pt.
precision
XLine extend line length DEFine define macro
FORmat relax FORMAT type checking WILd relax wild branch
checking
TErminal display diagnostic messages Quiet operate quietly
RESources messages in resource file CC devices are carriage
control
LFwithff LF with FF DEPendency generate file
dependencies
SR save/restore segment regs FSfloats FS not fixed
GSfloats GS not fixed SC stack calling convention
EZ Easy OMF-386 object files SG automatic stack growing
SYntax syntax check only LIBinfo generate default
libraries
DT set data threshold AUtomatic local variables on the
stack
DEScriptor pass character descriptors SAve SAVE local variables
COde constants in code segment ALign align COMMON segments
MAngle mangle COMMON segment names IPromote promote intrinsic
arguments
SEpcomma allow comma separator
Marty Stanquist
hello_world.f90
--------------------
program hello
print *, "F03 Hello World!\n"
do i = 1, 10
print *, i, " squared is ", i*i
end do
print *, "\nBye!"
end program hello
--------------------
c:\SwDev\OW\bld\F03\wfc\nt386.386>.\wfc386.exe hello_world.f90 >
hello_world.log
2>&1
Open Watcom Fortran 2003/32 Experimental Compiler Version 0.1 2011/07/09
18:32
:35
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
hello_world.f90(1): *ERR* CC-02 invalid character in statement number
columns
hello_world.f90(3): *ERR* CC-02 invalid character in statement number
columns
+============+===========+=============+
|| Line : 1 ||
+============+===========+=============+
+ Address: 0x001c7880 ( 1) +
+============+===========+=============+
+ Link: 0x001c78c0 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_NAM |FT_NO_TYPE |
| 1 | 1 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: PROGRAMHELLO |
+------------+-----------+-------------+
+============+===========+=============+
+ Address: 0x001c78c0 ( 2) +
+============+===========+=============+
+ Link: 0x00000000 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_PHI |FT_NO_TYPE |
| 1 | 0 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
+============+===========+=============+
|| Line : 3 ||
+============+===========+=============+
+ Address: 0x001c78c0 ( 1) +
+============+===========+=============+
+ Link: 0x001c7880 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_NAM |FT_NO_TYPE |
| 1 | 1 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: PRINT |
+------------+-----------+-------------+
+============+===========+=============+
+ Address: 0x001c7880 ( 2) +
+============+===========+=============+
+ Link: 0x001c8908 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_MUL | OPN_PHI |FT_NO_TYPE |
| 24 | 0 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
+============+===========+=============+
+ Address: 0x001c8908 ( 3) +
+============+===========+=============+
+ Link: 0x001c8948 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_COM | OPN_PHI |FT_NO_TYPE |
| 4 | 0 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
+============+===========+=============+
+ Address: 0x001c8948 ( 4) +
+============+===========+=============+
+ Link: 0x00000000 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_PHI |FT_NO_TYPE |
| 1 | 0 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
+============+===========+=============+
|| Line : 3 ||
+============+===========+=============+
+ Address: 0x001c8948 ( 1) +
+============+===========+=============+
+ Link: 0x001c8908 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_PHI |FT_NO_TYPE |
| 1 | 0 | 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
+============+===========+=============+
+ Address: 0x001c8908 ( 2) +
+============+===========+=============+
+ Link: 0x00000000 +
+ Arglist: 0x00000000 +
+------------+-----------+-------------+
| OPR_TRM | OPN_PHI |FT_NO_TYPE |
| 1 | 0 hello_world.f90(3): *ERR* ST-19 column 13, expecting
keyword or symbolic name
hello_world.f90(3): *ERR* ST-19 column 13, expecting keyword or symbolic
name
hello_world.f90(3): *ERR* ST-19 column 13, expecting keyword or symbolic
name
hello_world.f90(3): *ERR* ST-19 column 13, expecting keyword or symbolic
name
| 0 |
+------------+-----------+-------------+
| Flags: 000000 |
| Operand: |
+------------+-----------+-------------+
*** Double quote comments cause infinite loop, doing Cntrl-C ***
Marty Stanquist
double quotes "" and the named end statement. It's possible that something
broke during the build. But I'll start looking closely at the code to see if
any Fortran language updates were implemented.
Marty
Peter C. Chapin
It is likely that the F03 branch is very immature and probably doesn't
even know about free formatted source. My understanding is that it is
basically a copy of the trunk F77 compiler with essentially no
significant additions.
That said, I'm not the person who worked on it so I might be
underestimating how far along it is.
Peter
Bartosz Polednia
http://perforce.openwatcom.org:4000/@md=d&cd=//&c=HEL@//?ac=43&mx=50&u=HartmuthG
Bartosz
Marty Stanquist
website, early WATFOR-77 compilers also ran on the IBM 370. Do know if there
any mainframe users left and if so, what requirements they may have?
Marty
Marty Stanquist
wfc\c\compstmt.c, where Fortran language consistency checks are made prior
to statement action processing. While there are a few cosmetic differences
between F03 and f77, the program logic is identical. For related files,
wfc\c\kwlist.c, proctbl.c, cftable.c, wfc\h\prdefn.h and stmtdefn.h, the
same set of keywords, action routines, and flags are used. I would have
expected some differences in this area of the compiler if additional
language features were being supported. I also didn't see any references to
the fixed (vs. free) statement formatting, but I suspect that this is
handled by the lexer. I will continue reviewing the code this week to get a
better understanding of how it works.
Marty
Marty Stanquist
wfc386.exe and wfl386.exe trying to compile hello_world.f90. I am finding
that the previous team made some changes to the English character set tables
used by the lexical scanner to support Fortran 1995. This is file
F03\c\english.c. The lexical scanner is file F03\wfc\c\scan.c and the
lexical analyzer is file F03\wfc\c\lex.c. When debugging wfc386.exe, the
lexical scanner seems to recognize the statements in hello_world.f90, but
two error flags, scan_error and AError, are getting set which cause the
scanner to abort. When the flags are forced to zero, the lexical analyzer
builds data structures for the statements and tries to branch to the
appropriate action routines. I'm still looking at what might be setting
these flags and whether there is appropriate program logic for processing
Fortran 1990 and above statements. At least now I can debug the code.
Marty
Marty Stanquist
enumeration constants C_xx are all correct:
file bld/f77/c/english.c
// 10 DLE 11 DC1 12 DC2 13 DC3 14 DC4 15 NAK 16 SYN 17ETB
^^^^^
line 127, column 55 should be 17 ETB
// 18 CAN 19 EM 1A SUB 1B ESC 1C FS 1D GS 1E RS 1FUS
^^^^
line 130, column 55 should be 1F US
// 20 SP 21 ! 22 " 23 & 24 $ 25 % 26 & 27'
^^^^
^^^
line 133, column 27 should be 23 #
line 133, column 55 should be 27 '
// 58 X 59 Y 5A Z 5B [ 5C \ 5D ] 5E @ 5F _
^^^^
line 154, column 48 should be 5E ^
These are a few suggestions for your f77 cleanup list.
Marty
"Bartosz Polednia" wrote in message news:ivci1n$c73$1...@www.openwatcom.org...
Marty Stanquist
errors or warnings and generates a valid 32-bit object file that can be
disassembled using wdis. This is shown below. I am currently working with
the Fortran runtime library in preparation for running regression tests
using Nist's updated 1995 compatible Fortran test suite. I am anticipating
the new compiler having command line switches for strict 1977 compliance,
strict 1995 compliance, and depreciated statement warnings. The default mode
will be to compile with 2003 and above compliance allowing depreciated
statements with no warnings. Once I get F03 to compile the new Nist test
suite and have it running in the debugger, I'll start a new thread to update
Fortran 2012 status.
Marty
------------------
hello_world.f90
program hello
print *, "F03 Hello World!\n"
do i = 1, 10
print *, i, " squared is ", i*i
end do
print *, "bye!\n"
end program hello
------------------
wmake /a /sn
wfc386 hello_world.f90 -d2 > hello_world.log
wdis hello_world /l /e /p /s /fu
Module: c:\SwDev\OW\bld\F03\wfc\nt386.386\hello_world.f90
GROUP: 'DGROUP' CONST,_DATA,_BSS
Segment: CONST PARA USE32 00000024 bytes
0000 L$1:
0000 62 79 65 21 5C 6E bye!\n
0006 L$2:
0006 20 73 71 75 61 72 65 64 20 69 73 20 squared is
0012 L$3:
0012 46 30 33 20 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 F03 Hello World!
0022 5C 6E \n
Segment: _DATA PARA USE32 00000018 bytes
0000 L$4:
0000 00 00 00 00 DD offset L$1
0004 06 00 00 00 ....
0008 L$5:
0008 06 00 00 00 DD offset L$2
000C 0C 00 00 00 ....
0010 L$6:
0010 12 00 00 00 DD offset L$3
0014 12 00 00 00 ....
Segment: _BSS PARA USE32 00000000 bytes
BSS Size: 0 bytes
Segment: .debug_info BYTE USE32 000000CE bytes
0000 L$7:
0000 CA 00 00 00 02 00 ......
0006 00 00 00 00 DD offset L$9
000A 04 06 CD 00 00 00 63 3A 5C 53 77 44 65 76 5C 4F ......c:\SwDev\O
001A 57 5C 62 6C 64 5C 46 30 33 5C 77 66 63 5C 6E 74 W\bld\F03\wfc\nt
002A 33 38 36 2E 33 38 36 5C 68 65 6C 6C 6F 5F 77 6F 386.386\hello_wo
003A 72 6C 64 2E 66 39 30 00 rld.f90.
0042 00 00 00 00 DD offset L$8
0046 07 00 56 31 2E 30 20 57 41 54 43 4F 4D 00 00 ..V1.0 WATCOM..
0055 00 00 00 00 DD offset L$10
0059 00 00 00 00 01 .....
005E 04 00 00 00 DD offset L$11
0062 09 00 07 01 09 00 07 04 09 00 05 01 09 00 05 02 ................
0072 09 00 05 04 09 00 04 04 09 00 04 08 09 00 04 08 ................
0082 09 00 03 08 09 00 03 10 09 00 03 10 7E CC 00 00 ............~...
0092 00 01 0E 46 4D 41 49 4E 00 01 00 01 01 00 00 02 ...FMAIN........
00A2 91 18 ..
00A4 00 00 00 00 DD offset FMAIN
00A8 83 00 00 00 DD offset L$16
00AC 00 01 55 66 CB 00 00 00 ..Uf....
00B4 0E 00 00 00 DD offset L$12
00B8 7A 00 00 00 DD offset L$15
00BC D2 01 01 00 00 49 00 02 91 78 72 00 00 00 00 00 .....I...xr.....
00CC 00 00 ..
Segment: .debug_pubnames BYTE USE32 0000001C bytes
0000 18 00 00 00 02 00 ......
0006 00 00 00 00 DD offset L$7
000A 00 00 00 00 8E 00 00 00 46 4D 41 49 4E 00 00 00 ........FMAIN...
001A 00 00 ..
Segment: .debug_aranges BYTE USE32 0000002C bytes
0000 28 00 00 00 02 00 (.....
0006 00 00 00 00 DD offset L$7
000A 04 00 ..
000C 00 00 00 00 DD offset FMAIN
0010 83 00 00 00 ....
0014 00 00 00 00 DD offset L$1
0018 24 00 00 00 $...
001C 00 00 00 00 DD offset L$4
0020 18 00 00 00 00 00 00 00 00 00 00 00 ............
Segment: .debug_line BYTE USE32 00000066 bytes
0000 L$8:
0000 62 00 00 00 02 00 10 00 00 00 01 00 FF 04 0A 00 b...............
0010 01 01 01 01 00 00 00 00 00 00 00 36 03 63 3A 5C ...........6.c:\
0020 53 77 44 65 76 5C 4F 57 5C 62 6C 64 5C 46 30 33 SwDev\OW\bld\F03
0030 5C 77 66 63 5C 6E 74 33 38 36 2E 33 38 36 5C 68 \wfc\nt386.386\h
0040 65 6C 6C 6F 5F 77 6F 72 6C 64 2E 66 39 30 00 00 ello_world.f90..
0050 00 00 00 05 02 .....
0055 00 00 00 00 DD offset FMAIN
0059 06 05 01 01 45 5D 68 AC 21 5D 00 01 01 ....E]h.!]...
Segment: .debug_loc BYTE USE32 00000000 bytes
Segment: .debug_abbrev BYTE USE32 00000069 bytes
0000 L$9:
0000 06 11 01 01 13 03 08 10 06 13 0F 1B 08 25 08 42 .............%.B
0010 0F 43 06 35 10 82 41 0B 83 41 06 00 00 09 24 00 .C.5..A..A....$.
0020 03 08 3E 0B 0B 0B 00 00 7E 2E 01 01 13 32 0B 2C ..>.....~....2.,
0030 0F 03 08 3F 0C 20 0B 36 0B 27 0C 4C 0B 34 0C 2A ...?. .6.'.L.4.*
0040 0A 11 01 12 01 33 0B 40 0A 00 00 66 0B 01 01 13 .....3.@...f....
0050 11 01 12 01 00 00 D2 01 34 00 32 0B 3F 0C 34 0C ........4.2.?.4.
0060 03 08 02 0A 49 13 00 00 00 ....I....
Segment: .debug_macinfo BYTE USE32 00000001 bytes
0000 L$10:
0000 00 .
Segment: .debug_str BYTE USE32 00000000 bytes
Segment: .WATCOM_references BYTE USE32 00000004 bytes
0000 00 00 00 00 ....
0004 L$11:
Segment: _TEXT BYTE USE32 00000083 bytes
program hello
0000 FMAIN:
0000 53 PUSH EBX
0001 51 PUSH ECX
0002 52 PUSH EDX
0003 56 PUSH ESI
0004 57 PUSH EDI
0005 55 PUSH EBP
0006 89 E5 MOV EBP,ESP
0008 81 EC 08 00 00 00 SUB ESP,0x00000008
print *, "F03 Hello World!\n"
000E L$12:
000E E8 00 00 00 00 CALL RT@IOOpen
0013 B8 10 00 00 00 MOV EAX,offset L$6
0018 E8 00 00 00 00 CALL RT@OutSTR
001D E8 00 00 00 00 CALL RT@Alloc
do i = 1, 10
0022 B8 0A 00 00 00 MOV EAX,0x0000000a
0027 C7 45 F8 01 00 00 00 MOV dword ptr -0x8[EBP],0x00000001
002E 89 45 FC MOV dword ptr -0x4[EBP],EAX
0031 L$13:
0031 8B 45 F8 MOV EAX,dword ptr -0x8[EBP]
0034 3B 45 FC CMP EAX,dword ptr -0x4[EBP]
0037 7F 2D JG L$14
print *, i, " squared is ", i*i
0039 E8 00 00 00 00 CALL RT@IOOpen
003E 8B 45 F8 MOV EAX,dword ptr -0x8[EBP]
0041 E8 00 00 00 00 CALL RT@OutREAL
0046 B8 08 00 00 00 MOV EAX,offset L$5
004B E8 00 00 00 00 CALL RT@OutSTR
0050 8B 45 F8 MOV EAX,dword ptr -0x8[EBP]
0053 0F AF 45 F8 IMUL EAX,dword ptr -0x8[EBP]
0057 E8 00 00 00 00 CALL RT@OutREAL
005C E8 00 00 00 00 CALL RT@Alloc
end do
0061 FF 45 F8 INC dword ptr -0x8[EBP]
0064 EB CB JMP L$13
print *, "bye!\n"
0066 L$14:
0066 E8 00 00 00 00 CALL RT@IOOpen
006B B8 00 00 00 00 MOV EAX,offset L$4
0070 E8 00 00 00 00 CALL RT@OutSTR
0075 E8 00 00 00 00 CALL RT@Alloc
end program hello
007A L$15:
007A 89 EC MOV ESP,EBP
007C 5D POP EBP
007D 5F POP EDI
007E 5E POP ESI
007F 5A POP EDX
0080 59 POP ECX
0081 5B POP EBX
0082 C3 RET
0083 L$16:
Routine Size: 131 bytes, Routine Base: _TEXT + 0000
No disassembly errors
List of external references
SYMBOL
-------
RT@Alloc 001E 005D 0076
RT@IOOpen 000F 003A 0067
RT@OutREAL 0042 0058
RT@OutSTR 0019 004C 0071
List of public symbols
SYMBOL SECTION OFFSET
--------------------------------------------------------
FMAIN _TEXT 00000000
------------------
Peter C. Chapin
> Just a quick F03 update. Wfc386 now compiles file hello_world.90 without
> errors or warnings and generates a valid 32-bit object file that can be
> disassembled using wdis...
This all sounds great, Marty. Thanks for your efforts in this area. It's
good to see the Fortran compiler making progress.
Peter