- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I have inherited a code that I am trying to compile and run using the Intel Visual Fortran compiler (and MS Visual Studio 2005). The FORTRAN code has calls to a subroutine that was written in Assembly language. I am trying to compile from the command line and get the following error,
> ifort foo1.f90 foo2.asm
Assembling: foo2.asm
foo2.asm(49) : error A2214: GROUP directive not allowed with the /coff option
Infoo2.asm, on and about line 49 is the code,
48 CODE SEGMENT USE32 BYTE PUBLIC 'CODE'
49 CGROUP GROUP CODE
50 ASSUME CS:CGROUP
I have also tried compiling the Assembly code using the Borland Turbo Assembler, TASM as,
> tasm foo2.asm
This has worked and created a file, foo2.obj. I then tried to use this with the Intel compiler and got the following error,
> ifort foo1.f90 foo2.obj
foo2.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0x8F0
What I am trying to do has been done in the past using the Compaq Visual Fortran compiler version 6.6.
I do not know anything about Assembly language or what is being done in the routine.
Any assistance someone could provide in helping me compile and link these 2 codes would be greatly appreciated!
Thank you very much.
Sincerely,
David
I have inherited a code that I am trying to compile and run using the Intel Visual Fortran compiler (and MS Visual Studio 2005). The FORTRAN code has calls to a subroutine that was written in Assembly language. I am trying to compile from the command line and get the following error,
> ifort foo1.f90 foo2.asm
Assembling: foo2.asm
foo2.asm(49) : error A2214: GROUP directive not allowed with the /coff option
Infoo2.asm, on and about line 49 is the code,
48 CODE SEGMENT USE32 BYTE PUBLIC 'CODE'
49 CGROUP GROUP CODE
50 ASSUME CS:CGROUP
I have also tried compiling the Assembly code using the Borland Turbo Assembler, TASM as,
> tasm foo2.asm
This has worked and created a file, foo2.obj. I then tried to use this with the Intel compiler and got the following error,
> ifort foo1.f90 foo2.obj
foo2.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0x8F0
What I am trying to do has been done in the past using the Compaq Visual Fortran compiler version 6.6.
I do not know anything about Assembly language or what is being done in the routine.
Any assistance someone could provide in helping me compile and link these 2 codes would be greatly appreciated!
Thank you very much.
Sincerely,
David
Link Copied
15 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you add a .asm file on the ifort line, you are using the Microsoft Assembler or MASM, run independently using the command ml (or ml64 for 64-bit). It generates object files that are link-compatible with IVF. The Borland assembler does not create such files.
If you want documentation on the Microsoft Assembler, you can find it at MSDN. With CVF, you used an earlier version of the Microsoft Assembler which, I guess, had different rules. I can find documentation of the A2214 error, but it just repeats what the error message says. I don't know much at all about MASM - it is part of Visual Studio and not part of the Fortran product.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Steve Lionel (Intel)
When you add a .asm file on the ifort line, you are using the Microsoft Assembler or MASM, run independently using the command ml (or ml64 for 64-bit). It generates object files that are link-compatible with IVF. The Borland assembler does not create such files.
If you want documentation on the Microsoft Assembler, you can find it at MSDN. With CVF, you used an earlier version of the Microsoft Assembler which, I guess, had different rules. I can find documentation of the A2214 error, but it just repeats what the error message says. I don't know much at all about MASM - it is part of Visual Studio and not part of the Fortran product.
Thanks again for your help.
Sincerely,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
David,
When stuck, try this.
Create a dummy .F90 subroutine (same name same number/types of args).
Set option switches for Fortran to create and save Assembler File.
Look at output and glean differences between what you are doing and what IVF does.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - jimdempseyatthecove
David,
When stuck, try this.
Create a dummy .F90 subroutine (same name same number/types of args).
Set option switches for Fortran to create and save Assembler File.
Look at output and glean differences between what you are doing and what IVF does.
Jim Dempsey
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
David,
You can use the technique I described to create and empty function in .ASM format. Then you can remove the dummy.f90 file from the project and add in the .asm file. Then fill in the body of the function. After you do this once or twice, you can then feel comfortable with starting with a .ASM file.
I did this about 4 years ago on older version of IVF (8.nn)and haven't had to do this on the newer compilers.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - david.sallngc.com
Hi!
I have inherited a code that I am trying to compile and run using the Intel Visual Fortran compiler (and MS Visual Studio 2005). The FORTRAN code has calls to a subroutine that was written in Assembly language. I am trying to compile from the command line and get the following error,
> ifort foo1.f90 foo2.asm
Assembling: foo2.asm
foo2.asm(49) : error A2214: GROUP directive not allowed with the /coff option
Infoo2.asm, on and about line 49 is the code,
48 CODE SEGMENT USE32 BYTE PUBLIC 'CODE'
49 CGROUP GROUP CODE
50 ASSUME CS:CGROUP
I have also tried compiling the Assembly code using the Borland Turbo Assembler, TASM as,
> tasm foo2.asm
This has worked and created a file, foo2.obj. I then tried to use this with the Intel compiler and got the following error,
> ifort foo1.f90 foo2.obj
foo2.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0x8F0
What I am trying to do has been done in the past using the Compaq Visual Fortran compiler version 6.6.
I do not know anything about Assembly language or what is being done in the routine.
Any assistance someone could provide in helping me compile and link these 2 codes would be greatly appreciated!
Thank you very much.
Sincerely,
David
I have inherited a code that I am trying to compile and run using the Intel Visual Fortran compiler (and MS Visual Studio 2005). The FORTRAN code has calls to a subroutine that was written in Assembly language. I am trying to compile from the command line and get the following error,
> ifort foo1.f90 foo2.asm
Assembling: foo2.asm
foo2.asm(49) : error A2214: GROUP directive not allowed with the /coff option
Infoo2.asm, on and about line 49 is the code,
48 CODE SEGMENT USE32 BYTE PUBLIC 'CODE'
49 CGROUP GROUP CODE
50 ASSUME CS:CGROUP
I have also tried compiling the Assembly code using the Borland Turbo Assembler, TASM as,
> tasm foo2.asm
This has worked and created a file, foo2.obj. I then tried to use this with the Intel compiler and got the following error,
> ifort foo1.f90 foo2.obj
foo2.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0x8F0
What I am trying to do has been done in the past using the Compaq Visual Fortran compiler version 6.6.
I do not know anything about Assembly language or what is being done in the routine.
Any assistance someone could provide in helping me compile and link these 2 codes would be greatly appreciated!
Thank you very much.
Sincerely,
David
Hello
Your assembly code seems to be designed for 16bits applications and not for .386 mode applications (32bits). So, if true, it is not compatible with the /coff option which is designed for builiding 32bits obj files.
Can you join the assembly file and I will look at your code. I wil try to know if it is possible to convet it to 32bits mode or if not to understand what it is supposed to do.
Best regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - gvautier
Hello
Your assembly code seems to be designed for 16bits applications and not for .386 mode applications (32bits). So, if true, it is not compatible with the /coff option which is designed for builiding 32bits obj files.
Can you join the assembly file and I will look at your code. I wil try to know if it is possible to convet it to 32bits mode or if not to understand what it is supposed to do.
Best regards
Hi gvautier!
I have attached a copy of the code. Thank you very much for looking at it. Any help you could provide would be greatly appreciated!
Sincerely,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
David,
;MODIFIED DATE: 8-11-04
;REASON: TO WORK WITH COMPAQ VISUAL FORTRAN
;PROBLEM: VISUAL FORTRAN PUSHED ALL THE ARGUMENTS SENT
; TO BULK IN TO STACK, BUT BULK WAS NOT MADE
; TO COMPENSATE FOR THAT. SO WE LOST 44 PLACES
; OFF STACK EACH TIME IT RAN.
;SOLUTION: AT THE END OF THE CODE I CHANGED RET TO RET 2CH
; THIS FREES 44 PLACES OF MEMORY
The above is Pascal calling sequence. The subroutine called is responsible for stack cleanup.
Intel IVF uses cdecl calling convention. The caller of the subroutine is responsible for stack cleanup.
Start with changing all occurances of
;old code
; RET
;MODIFIED 8-11-04
;new code
RET 2ch
with
IF 1
; MODIFIED 9-4-09
; IVF uses cdecl
RET
ELSE
;old code
; RET
;MODIFIED 8-11-04
;new code
RET 2ch
ENDIF
I would suggest also changing "IF 1" to "IF _CDECL_" and then properly define _CDECL_ (0 or 1)
Also, for Intel64 the code will require additional changes (using 64-bit registers and using FASTCALL calling conventions)
*** Again, I must re-iterate ***
Write and empty subroutine taking the same arguments as your ASM routine.
The body of this subroutine containing
CLOSE(99)
Produce the ASM listing from IVF
You are not interested in closing io unit99
Rather the abvewill produce a simple push of reference to 99 and CALL to IVF close routine.
Those statements in the assembler will be easy to identify in the ASM listing.
Replace those statements with
; ********************************************
This is a line of demarcation.
Above that line of demarcation is the subroutine prolog.
Following that line of demarcation is the subroutine epilog.
Incorporate the IVF prolog into your subroutine entry
Incorporate the IVF epilog into all of your subroutines exit.
You may also wish to follow the same procedure with the subroutine marked as PURE and/or ELEMENTAL(assuming your code does not alter state in a manner contrary to PURE and/or ELEMENTAL)
This may or may not affect the prolog and/or epilog, but it will affect how the optimizer produces the code of the caller. (This ASM routine should have an INTERFACE declaration in the .F90 code)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just have a short look at the code. It seems to be 32bits code but not designed to be assembled by MASM.
If you kow what the functions included are intented to do, my best advice is to rewrite them in Fortran or C. Well optimised high level code will today ever run rather as fast as assembly and will be easier to maintain.
If, as indicated in the header, that code was modifed to run with CVF I think that a little change in declarations will allow it to be assembled by MASM. But you must keep the CVF interface declaration.
I will try to adapt the code today.
If you kow what the functions included are intented to do, my best advice is to rewrite them in Fortran or C. Well optimised high level code will today ever run rather as fast as assembly and will be easier to maintain.
If, as indicated in the header, that code was modifed to run with CVF I think that a little change in declarations will allow it to be assembled by MASM. But you must keep the CVF interface declaration.
I will try to adapt the code today.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - gvautier
I just have a short look at the code. It seems to be 32bits code but not designed to be assembled by MASM.
If you kow what the functions included are intented to do, my best advice is to rewrite them in Fortran or C. Well optimised high level code will today ever run rather as fast as assembly and will be easier to maintain.
If, as indicated in the header, that code was modifed to run with CVF I think that a little change in declarations will allow it to be assembled by MASM. But you must keep the CVF interface declaration.
I will try to adapt the code today.
If you kow what the functions included are intented to do, my best advice is to rewrite them in Fortran or C. Well optimised high level code will today ever run rather as fast as assembly and will be easier to maintain.
If, as indicated in the header, that code was modifed to run with CVF I think that a little change in declarations will allow it to be assembled by MASM. But you must keep the CVF interface declaration.
I will try to adapt the code today.
That would be fantastic if you could modify it for me! Thank you so much.
The person who wrote the code passed away a few years ago. The .asm file is called by a FORTRAN code (this I can understand) but I do not know exactly what the assembly code is trying to do (I think it is providing some type of indexing or arrays). If you could modify it for me to compile using the ml.exe compiler (from MS Visual Studio 2005), that would basically solve my problem.
Thank you again gvautier!
Sincerely,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - david.sallngc.com
Hi gvautier!
That would be fantastic if you could modify it for me! Thank you so much.
The person who wrote the code passed away a few years ago. The .asm file is called by a FORTRAN code (this I can understand) but I do not know exactly what the assembly code is trying to do (I think it is providing some type of indexing or arrays). If you could modify it for me to compile using the ml.exe compiler (from MS Visual Studio 2005), that would basically solve my problem.
Thank you again gvautier!
Sincerely,
David
That would be fantastic if you could modify it for me! Thank you so much.
The person who wrote the code passed away a few years ago. The .asm file is called by a FORTRAN code (this I can understand) but I do not know exactly what the assembly code is trying to do (I think it is providing some type of indexing or arrays). If you could modify it for me to compile using the ml.exe compiler (from MS Visual Studio 2005), that would basically solve my problem.
Thank you again gvautier!
Sincerely,
David
Hello
It is rather simple :
add
.MODEL FLAT,STDCALL
after
.486
and replace :
CODE SEGMENT USE32 BYTE PUBLIC 'CODE'
CGROUP GROUP CODE
ASSUME CS:CGROUP
PUBLIC BULK3,BULK2
by
.CODE
The attached file is modified and as been assembled successfully.
Do you want I try to convert it to pseudo code?
Best regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I looked at the assembly code.
It is very complex and appears to do some very dangerous things (in term of portability) such as using the stack frame of the function as storage for temporary variables instead of creating local variables and optional arguments if I have well understand.
I repeat my advice to search for the algorithm and rewrite it in Fortran or C.
Can you give me the interface of the two functions and the description of the parameters (FLD(*) and IC(*)) that seem to be structures.
It is very complex and appears to do some very dangerous things (in term of portability) such as using the stack frame of the function as storage for temporary variables instead of creating local variables and optional arguments if I have well understand.
I repeat my advice to search for the algorithm and rewrite it in Fortran or C.
Can you give me the interface of the two functions and the description of the parameters (FLD(*) and IC(*)) that seem to be structures.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - gvautier
I looked at the assembly code.
It is very complex and appears to do some very dangerous things (in term of portability) such as using the stack frame of the function as storage for temporary variables instead of creating local variables and optional arguments if I have well understand.
I repeat my advice to search for the algorithm and rewrite it in Fortran or C.
Can you give me the interface of the two functions and the description of the parameters (FLD(*) and IC(*)) that seem to be structures.
It is very complex and appears to do some very dangerous things (in term of portability) such as using the stack frame of the function as storage for temporary variables instead of creating local variables and optional arguments if I have well understand.
I repeat my advice to search for the algorithm and rewrite it in Fortran or C.
Can you give me the interface of the two functions and the description of the parameters (FLD(*) and IC(*)) that seem to be structures.
Thank you very much for all of your help. I would love to rewrite the function in FORTRAN but I do not know Assembly Language and thus, do not know what the function is doing. If you could write pseudocode, that would be fabulous. I can send you the INTERFACE statements and the descriptions of FLD and IC, but it will have to be on Tuesday. I did not bring home the code this weekend and Moday is a Holiday.
Perhaps we should do this via an email address as opposed to the Intel Forum. You can reach me at david.sall@gmail.com. If you could send me a quick email then I will know where to send the information.
Thank you again gvautier!
Sincerely,
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Steve Lionel (Intel)
When you add a .asm file on the ifort line, you are using the Microsoft Assembler or MASM, run independently using the command ml (or ml64 for 64-bit). It generates object files that are link-compatible with IVF. The Borland assembler does not create such files.
If you want documentation on the Microsoft Assembler, you can find it at MSDN. With CVF, you used an earlier version of the Microsoft Assembler which, I guess, had different rules. I can find documentation of the A2214 error, but it just repeats what the error message says. I don't know much at all about MASM - it is part of Visual Studio and not part of the Fortran product.
HI Steve
Here some info i have found which might help you (Microsoft Macro Assembler Reference
ML Nonfatal Error A2214
GROUP directive not allowed with /coff option
The GROUP directive is not permitted when compiling with /coff.
See ML and ML64 Command-Line Reference for more information).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Triple Thunder, but as I noted the "more information" just repeats the error message. This thread seems to be under control, thanks to the helpfulness of the community!

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page