{"id":11943,"date":"2010-12-22T07:00:00","date_gmt":"2010-12-22T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/12\/22\/the-__fortran-calling-convention-isnt-the-calling-convention-used-by-fortran\/"},"modified":"2010-12-22T07:00:00","modified_gmt":"2010-12-22T07:00:00","slug":"the-__fortran-calling-convention-isnt-the-calling-convention-used-by-fortran","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20101222-00\/?p=11943","title":{"rendered":"The __fortran calling convention isn&#039;t the calling convention used by FORTRAN"},"content":{"rendered":"<p>\nAlthough the Microsoft C compiler supports a calling convention called\n<code>__fortran<\/code>,\nthat&#8217;s just what the calling convention is called;\nits relationship with the FORTRAN programming language is only coincidental.\nThe <code>__fortran<\/code> keyword is now just an old-fashioned\nsynonym for <code>__stdcall<\/code>.\n<\/p>\n<p>\nVarious FORTRAN compilers use different calling conventions;\nthe one I describe here applies to the now-defunct\nMicrosoft Fortran PowerStation.\n<\/p>\n<p>\nFortran Powerstation pushes parameters on the stack right-to-left,\nwith callee-cleanup.\n(So far, this matches\n<code>__fortran<\/code> aka <code>__stdcall<\/code>.)\nFunction names are\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa278674(VS.60).aspx\">\nconverted to all-uppercase, with an underscore\nat the beginning and <code>@n<\/code> appended<\/a>,\nwhere <code>n<\/code> is the number of bytes of parameters.\n(This still matches <code>__stdcall<\/code> aside from the uppercase\nconversion.)\n<\/p>\n<p>\nAs for how the parameters are passed, well, that&#8217;s where things\nget weird.\nFORTRAN natively\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa294334(VS.60).aspx\">\npasses all parameters by reference<\/a>.\nThis is the source of a famous classic FORTRAN bug known as\n<i>constants aren&#8217;t<\/i>.\n<\/p>\n<pre>\n      PROGRAM MYSTERY\n      CALL MAGIC(1)\n      PRINT *, 'According to the computer, 3 + 1 is ', ADDUP(3, 1)\n      END\n      FUNCTION ADDUP(I, J)\n      ADDUP = I + J\n      END\nC     What does this subroutine actually do?\n      SUBROUTINE MAGIC(I)\n      I = 9\n      RETURN\n      END\n<\/pre>\n<p>\n(It&#8217;s been a long time since I&#8217;ve written a FORTRAN program,\nso I may have gotten some of the details wrong,\nbut any errors shouldn&#8217;t detract from the fundamental issue.)\n<\/p>\n<p>\nWhen you run this program, it says\n<\/p>\n<pre>\nAccording to the computer, 3 + 1 is 12\n<\/pre>\n<p>\nHow did that happen?\nWe called a function that adds two numbers together,\nand instead of getting 4, we get 12?\n<\/p>\n<p>\nThe reason is the subroutine <code>MAGIC<\/code>:\nWe passed it the constant <code>1<\/code>,\nand since all FORTRAN parameters are passed by reference,\nthe assignment <code>I&nbsp;=&nbsp;9<\/code>\n<i>modifies the constant&nbsp;1<\/i>.\nIn C:\n<\/p>\n<pre>\nint One = 1;\nint Three = 3;\nint Nine = 9;\nvoid Magic(int *i) { *i = Nine; }\nint AddUp(int *i, int *j) { return *i + *j; }\nvoid main()\n{\n Magic(&amp;One);\n printf(\"According to the computer, 3 + 1 is %d\\n\",\n        AddUp(&amp;Three, &amp;One));\n}\n<\/pre>\n<p>\nSince <code>Magic<\/code> modified the constant <code>One<\/code>,\nany further use of the constant&nbsp;1 ends up using the value&nbsp;9!\n(According to the FORTRAN standard,\nmodifying a constant results in undefined behavior.)\n<\/p>\n<p>\nOkay, back to calling conventions.\nOther significant differences between C and FORTRAN:\nIn FORTRAN,\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa293547(VS.60).aspx\">\narray indices begin at 1, not 0,\nand arrays are stored in column-major order<\/a>\nrather than row-major as in C.\n<\/p>\n<p>\n<code>COMPLEX<\/code> variables in FORTRAN\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa296568(VS.60).aspx\">\nare stored as two floating point numbers<\/a>\n(corresponding to the real and imaginary components).\n<\/p>\n<p>\nFunctions which return <code>COMPLEX<\/code> or\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa236488(VS.60).aspx\">\n<code>CHARACTER*(*)<\/code><\/a>\nare internally rewritten as subroutines where the location to store the\nreturn value is passed as a hidden first parameter.\n(This is analogous to how C returns large structures.)\n<\/p>\n<p>\nThe final commonly-encountered\nweirdness of FORTRAN is that <code>CHARACTER*n<\/code> data types\n(which are used to hold strings) are\n<a HREF=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa236488(VS.60).aspx\">\npassed as <i>two<\/i> parameters<\/a>:\nThe address of the character buffer,\nfollowed by the size of the buffer&nbsp;(n).\nNote that FORTRAN <code>CHARACTER*n<\/code> variables are\nfixed-length;\nif you assign a string shorter than the buffer,\nit is padded with spaces.\nThere is no null terminator.\n<\/p>\n<p>\nAnyway, I sort of got carried away with the FORTRAN calling convention.\nIt&#8217;s definitely more complicated than just sticking\n<code>__fortran<\/code> in front of your function.\nBut at least the <code>__fortran<\/code> keyword takes care of the\npart that can&#8217;t be expressed in C.\nThe rest you can manage on your own.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Although the Microsoft C compiler supports a calling convention called __fortran, that&#8217;s just what the calling convention is called; its relationship with the FORTRAN programming language is only coincidental. The __fortran keyword is now just an old-fashioned synonym for __stdcall. Various FORTRAN compilers use different calling conventions; the one I describe here applies to the [&hellip;]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-11943","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"<p>Although the Microsoft C compiler supports a calling convention called __fortran, that&#8217;s just what the calling convention is called; its relationship with the FORTRAN programming language is only coincidental. The __fortran keyword is now just an old-fashioned synonym for __stdcall. Various FORTRAN compilers use different calling conventions; the one I describe here applies to the [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/11943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=11943"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/11943\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=11943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=11943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=11943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}