I have a pascal program which is compiled using Sun pascal 2.1, and I want to compile it by fpc now, but I got in some trouble. Reset procedure is used in that program but
Sun Pascal's reset: reset(file,filename), where filename is a string(See Sun Pascal 3.0.2 Reference Manual);
while FPC's reset:
procedure Reset(
var f: file;
l: LongInt
);(http://www.freepascal.org/docs-html/rtl/system/reset.html), so I got "incompatible type" error.
In my case, reset's 2nd parameter is an array of char, is it OK to just change it to reset(file, sizeof(array)), or should I choose anther compiler, like gpc, in which I found the 2nd parameter of reset is also string.
Start here:
http://wiki.freepascal.org/File_Handling_In_Pascal
But I second the motion to use more modern ways with streams and/or Stringlists.
An alternatives is Modern Pascal's CLI (www.ModernPascal.com). I wrote it to migrate Apple Pascal, and old Turbo Pascal to work on modern platforms. I support 99% of the older syntax, along with Web, dBase, etc. (I port legacy solutions to Linux, Mac, etc. this way).
Related
While attempting to use fftw3 libraries in VS2008 with Intel Fortran, I encountered a problem with the data types defined by the iso_c_binding.
Considering that fftw3 defines in fftw3.f03:
integer, parameter :: C_FFTW_R2R_KIND = C_INT32_T
When compiling a code with the line
integer(C_FFTW_R2R_KIND), dimension(*), intent(in) :: kind
I get the following error:
error #6684: This is an incorrect value for a kind type parameter in this context. [C_FFTW_R2R_KIND]
To understand the problem, I tried the following code
program test
implicit none
call sub()
contains
subroutine sub()
use, intrinsic :: iso_c_binding
implicit none
write(*,*) C_INT, C_DOUBLE , C_INT32_T, C_INT_FAST32_T, C_INT_LEAST32_T
end subroutine sub
end program test
After running, the following result is displayed:
4 8 -2 -2 -2
As -2 is not a valid data type, I assumed that was the problem and looking in https://software.intel.com/en-us/node/678431, I replaced the line in fftw3.f03 by this:
integer, parameter :: C_FFTW_R2R_KIND = 4 !C_INT32_T
And I can run the program without errors.
If anybody could confirm that this alternative is correct or how to solve the original problem I would appreciate it.
Your approach will work fine for Intel Fortran, although using SELECTED_INT_KIND(8) instead of 4 would be safer and more portable.
Intel Visual Fortran apparently uses Visual C++ as a companion C compiler. And apparently a version that does not supports these C99 types yet. AFAIK Visual C++ is more oriented towards C++ than C and does not bring new C standard features too fast. They are supported in recent versions though https://msdn.microsoft.com/en-us/library/323b6b3k.aspx
In my opinion it would be more useful for Intel Fortran to define the c_ kind values anyway even if the C compiler does not define those constants, but maybe it is not completely standard conforming. But I think it would be a useful extension.
You simply need a newer version of Intel Fortran. If you are using VS2008, you would be at most using version 14; the current version is 18 and your test program there produces the result:
4 8 4 4 4
I'm creating a VHDL project (Xilinx ISE for Spartan-6) that will be required to use decimal "real-style" numbers in either fixed/floating point (I'm hoping fixed point will be sufficient).
Being quite new to VHDL, I found out the hard way that the non-constant real types are not supported for synthesis, so I set about searching for a IP core or library to redress this.
So far I've found 3 options;
1) A floating point IP core provided by Xilinx
2) A downloadable "ieee_proposed" library written by a David Bishop found here
3) After spending a fair while attempting to work out how to "create" a new library with David Bishops files in, I took a quick look through the default IEEE library and saw it contains ieee.fixed_generic_pkg and ieee.fixed_pkg packages.
My question is - of the two libraries - which one would be sensible to use? Is one adapted for synthesis and one not, or one older than the other? And then if floating point is provided, is there any real point to the floating point IP core provided by Xilinx?
I've trawled through many questions of people attempting to add the ieee_proposed libraries, but none seem to have referenced the fact they they already seem to exist in the existing IEEE.
Thanks very much for any help!
============UPDATE (Essentially my own efforts to resolve)==================
I can't actually use the ieee.fixed_pkg - and attempting to do so gives me the error Cannot find <fixed_pkg> in library <ieee>.
After finding the ieee library at C:\Xilinx\14.7\ISE_DS\ISE\vhdl\xst\nt I've found that the fixed_pkg actually resides in ieee_proposed. However, this still throws up the same errors!
Dumb question, but when you downloaded the ieee_proposed did you also remember to compile it?
edit: And also remember to map the library to you simulation as well. Maybe you did all this already but these are the mistakes I make often.
I've been battling with the same problems for days.
The way I solved it is:
1. Add fixed_float_types_c, fixed_pkg_c and float_pkg_c vhdl files to project.
2. Declare them as belonging to work library (Properties in Quartus files window)
3. Compile project and call library using:
Library work;
use work.fixed_pkg.all;
To my annoyance, they don't come up in the nice red writing I want them to but it works!
I have a big, old, FORTRAN 77 code that has worked for many, many years with no problems.
Double-precision is not enough anymore, so to convert to quadruple-precision I have:
Replaced all occurrences of REAL*8 to REAL*16
Replaced all functions like DCOS() into functions like COS()
Replaced all built-in numbers like 0.d0 to 0.q0 , and 1D+01 to 1Q+01
The program compiles with no errors or warnings with the gcc-4.6 compiler on
operating system: openSUSE 11.3 x86_64 (a 64-bit operating system)
hardware: Intel Xeon E5-2650 (Sandy Bridge)
My LD_LIBRARY_PATH variable is set to the 64-bit library folder:
/gcc-4.6/lib64
The program reads an input file that has numbers in it.
Those numbers used to be of the form 1.234D+02 (for the double-precision version of the code, which works).
I have changed them so now that number is 1.234Q+02 , however I get the runtime error:
Bad real number in item 1 of list input
Indicating that the subroutine that reads in the data from the input file (called read.f) does not find the first number in the inputfile, to be compatible with what it expected.
Strangely, the quadruple-precision version of the code does not complain when the input file contains numbers like 1.234D+02 or 123.4 (which, based on the output seems to automatically be converted to the form 1.234D+02 rather than Q+02), it just does not like the Q+02 , so it seems that gcc-4.6 does not allow quadruple-precision numbers to be read in from input files in scientific notation !
Has anyone ever been able to read from an input file a quadruple-precision number in scientific notation (ie, like 1234Q+02) in FORTRAN with a gcc compiler, and if so how did you get it to work ? (or did you need a different compiler/operating system/hardware to get it to work ?)
Almost all of this is already in comments by #IanH and #Vladimi.
I suggest mixing in a little Fortran 90 into your FORTRAN 77 code.
Write all of your numbers with "E". Change your other program to write the data this way. Don't bother with "D" and don't try to use the infrequently supported "Q". (Using "Q" in constants in source code is an extension of gfortran -- see 6.1.8 in manual.)
Since you want the same source code to support two precisions, at the top of the program, have:
use ISO_FORTRAN_ENV
WP = real128
or
use ISO_FORTRAN_ENV
WP = real64
as the variation that changes whether your code is using double or quadruple precision. This is using the ISO Fortran Environment to select the types by their number of bits. (use needs to between program and implicit none; the assignment statement after implicit none.)
Then declare your real variables via:
real (WP) :: MyVar
In source code, write real constants as 1.23456789012345E+12_WP. The _type is the Fortran 90 way of specifying the type of a constant. This way you can go back and forth between double and quadruple precision by only changing the single line defining WP
WP == Working Precision.
Just use "E" in input files. Fortran will read according to the type of the variable.
Why not write a tiny test program to try it out?
How do i read in pascal a string and an integer in the same line like the C's scanf("%s %d", str, &n); version?
I am sorry, but I am pretty sure there is no way. You must read them separated.
Pascal does not have an equivilent of C's ...scanf() functions. You will have to either find a third-party implementation, write your own implementation, or just parse the string directly.
If from stdin:
read(s); read(i);
If not, then you are out of luck for Borland's Pascal variants. Free Pascal (2.4+) inherited a variant
from Apple(Standard Pascal derivative) variants that takes input from a string:
readstr(inputstr,s,i);
IIRC this is an Extended Pascal standard procedure that is commonly implemented by standard Pascal variants too, since it is basically a variant of the standard Pascal readln from input.
I am trying to look for definition and declaration of the function nanf() - return 'Not a Number function, which is related to the floating point functionality on Linux gcc compiler environment - (glibc).
I need to use similar/same definition for nanf() on windows to build my code using Visual Studio.
I checked following header files in the Linux src/include folders but did not see anything related to nanf declaration.
/usr/include/math.h
/usr/include/bits/nan.h
Any pointers will be helpful.
thank you,
-AD
The declaration is just (C99 ยง7.12.11.3):
float nanf(const char *tagp);
or macros that expand to something equivalent. A conformant implementation is highly platform-specific, however, because the standard does not define how to interpret tagp, except to say that the behavior is equivalent to a certain call to strtof, and "The nan functions return a quiet NaN, if available, with content indicated through tagp."
Instead of trying to shoehorn C99 features into the one compiler and library that stubbornly refuses to even try to implement them, why not just use a real C compiler? There are plenty out there.