In the general case the problem is unsolvable because when you shift the position of code it can shrink or grow in size causing an optimal solution to not exist.

I had the same problem in the ARM assembler when choosing between 16-bit and 32-bit encodings in thumb mode. One can end up with an infinite loops trying to find a solution. There would need to be some mechanism to detect such cases and essentially "give up" and move on.

Also, one needs to realise the fasm does not natively know about procedure/function demarcation points. That is all handled by the macros so if you do want to code a solution then the place to do it is in the macros.

The only case in which this could happen, is if two functions did a CALL to each other, which would be mutual recursion.

I'm trying to get my Forth VM to fit entirely in the 32K code-cache --- so, reducing code size is pretty important to me --- I'm planning on just doing the tedious manual fix-up after the program is finished, which I'm not looking forward to.

it can be done by macros

function_start:
  ;some code
function_size=$-function_start    

Hugh Aguilar wrote:

I'm trying to get my Forth VM to fit entirely in the 32K code-cache --- so, reducing code size is pretty important to me --- I'm planning on just doing the tedious manual fix-up after the program is finished, which I'm not looking forward to.

Note that a Forth system is different from most assembly-language programs --- a Forth system has a lot of functions (400ish), most of which are quite short (1 to 3 paragraphs), whereas the typical assembly-language program has relatively few functions which are relatively large. I'm saying "typical" here to describe what I've seen over the years --- although I don't really pay much attention to what other people are doing, so this may not be representative.

Anyway, because I'm writing a Forth system, this feature would help me more than it would help the "typical" FASM user. It should be pretty easy to implement though, so I would appreciate if it were done.

fasm is a multi-pass assembler. Function size can be determined at each pass with something like this:

Code:

function_start:
  ;some code
function_size=$-function_start    

align METHOD_ENTRY
Method1:
        ;
        ; ... some code here ...
        ;
        ret

align METHOD_ENTRY
Method2:
        ;
        ; ... some code here ...
        ;
        ret

... and so on in every file ...
    

I think the solution here is that the function will occupy the minimum number of 16-byte paragraphs if:
(function_start mod 16)+(function_size mod 16) < 16

macro FUNC {
        local function_start, function_size

        if (($-$$) mod 16)+(function_size mod 16) >= 16
          align 16
        end if

        function_start = $
        start@FUNC equ function_start
        size@FUNC equ function_size
}

macro FEND {
  size@FUNC = $ - start@FUNC
  restore start@FUNC
  restore size@FUNC 
}    

This is quite easy to be translated into a macro in fasm:

BTW: I asked the same question on the HLA mailing list, and Randy also said that it was easy and provided a macro --- so apparently all of you guys are way ahead of me.

These macros will not work in all cases.
They are a perfect example of a solution that will work for a good number of cases, but are not guaranteed to be optimal. However, they might work just fine for what you need to do. Especially if you're not changing branch displacements or data displacements by moving functions around.

I had previously been of the opinion that a macro assembler was a bad idea.

I thought that a better design would be to have a simple assembler without macros, and then have a separate preprocessor to provide the macro language. It is easier to write 2 small programs that do distinct jobs (assembling, and preprocessing) rather than 1 big program that does both.

Also, the preprocessor can be made to work with various assemblers for various micro-controllers, which wouldn't be possible if it were integrated into the assembler.

BTW: Does anybody here have an opinion on M4? I just recently heard about it. Right now, the most complicated thing that I'm doing with macros is building a linked-list at compile-time. The FASM macros are fine for this (as were HLA's, and NASM looks adequate too although I didn't delve into NASM). If I upgrade to a self-balancing binary tree in the future I would really be stretching your macro language, and I think a hash table would be impossible --- when that time comes, I may want to introduce a preprocessor. By then, my own language should be up and running, so I figured I would write the preprocessor in it, so it could help in generating version 2 of itself. But M4 might be another possibility. This is all in the future though --- right now, I can just use FASM macros for version 1.

The two best and possibly earliest examples of this are IBM's MVS assembler and their PL/I both of which have integrated macro languages.

m4 is an abomination. It is so complicated and ugly it's hard to understand the sick mind(s) that came up with it. There is no excuse for m4. There is always a better solution, even if it means writing your own from scratch. If it weren't for sendmail configuration files m4 could be wiped off the face of the earth and things would be that much the better for it.

dogman wrote:

The two best and possibly earliest examples of this are IBM's MVS assembler and their PL/I both of which have integrated macro languages.

I worked for almost 2 years as an IBM370 assembly-language programmer. I agree that it has a great macro language. I was the only person at my workplace who wrote reusable code, as everybody else just did cut-and-paste from old programs. I liked IBM370 assembly-language, but I found the mainframe culture to be rather sodden.

I don't know anything about PL/I, although I have heard other people say that it was a great language. Is it still used anywhere today?

dogman wrote:

m4 is an abomination. It is so complicated and ugly it's hard to understand the sick mind(s) that came up with it. There is no excuse for m4. There is always a better solution, even if it means writing your own from scratch. If it weren't for sendmail configuration files m4 could be wiped off the face of the earth and things would be that much the better for it.

I've heard other people say that it is ugly, although your reaction is stronger than most.

Sometimes the available program is so powerful as to be worth learning --- I doubt that is the case here though, as a preprocessor is not a complicated program to write (this is scripting language territory).

I will experiment with M4 a little bit --- even if I don't end up using it, I may yet learn some good ideas that I can incorporate into my own preprocessor.