FASM Updated
BlitzMax Forums/BlitzMax Programming/FASM Updated
| ||
| FASM has been updated to version 1.66 and I noticed the latest BlitzMax update only uses 1.64. Anyway the link is... http://flatassembler.net/download.php Try it out. |
| ||
| Try it out. Why? what difference do you think it will make? |
| ||
| You should always be using the latest stable release of FASM regardless of what BMax may ship with. |
| ||
| Yepp, thanks Kuron! |
| ||
| said who? I'll use what mark ships each update thanks... |
| ||
| Well, last time, updateting FASM to the latest version increased the speed of BlitzMax compiling by about 20%. BlitzMax shipped I believe with FASM 1.62 a few months ago and when users updated FASM themselves they got a speed increase in compile time. |
| ||
| said who? Any programmer you would ask?Mark has no control over FASM and doesn't develop it, but does rely on it. When a new version of FASM is released, it is to fix bugs, improve stuff, all of which Mark has no control over and can't fix himself. Unless you want a potentially buggy program, you should be using the latest stable release of FASM. In the past we have had some nasty compiling issues with BMax because it was using an outdated version of FASM. One time BMax couldn't compile large programs (bug in FASM fixed by upgrading to the latest which BMax didn't ship with), another time upgrading FASM gave a boost in compiling speed. If you are going to rely on third-party tools, you have to keep them updated if you want to produce stable and bug-free programs. |
| ||
| Well, after the update code compiles faster for me! But you can wait if you want... ;) |
| ||
| Always latest eh? shame that doesn't apply to mingw. |
| ||
| Always latest eh? shame that doesn't apply to mingw. Perhaps I am missing something, but mingw isn't required to use Bmax (you only need it if you want to monkey with modules and recompile them) ? |
| ||
| We should mention as well that the "user upgrade" to 1.64 lead to some problem as commandline calls had small differences that broke some BM apps. So its better to wait until it is official in BM if you want to prevent problems. |
| ||
| hooray for once Dreamora understood *and* agreed with me! ;p I'd far rather wait till Marks had chance to test it out if only because that way I can be sure of reporting a bug that is really a bug when using a non customised BlitzMax... |
| ||
| Use new version of FASM has no problem... I think next release of BM will inlude it... I hope they can also fix the DX7Lag and VTearing thing..... |
| ||
| And the MAX3D :) Mohahahahahaha! |
| ||
| I'm using it and it works just fine so far. |
| ||
| We should mention as well that the "user upgrade" to 1.64 lead to some problem as commandline calls had small differences that broke some BM apps. How odd that you are the ONLY blitzer that had that problem then. That pretty much speaks for itself, doesn't it? when using a non customised BlitzMax... You are not customizing BlitzMax in any way or changing anything in BMax. FASM is not a part of BlitzMax. It is a third-party tool that BMax uses and can 100% be safely upgraded just as any third-party tool can. That is the whole point and beauty of using third-party tools ;c) Customizing BlitzMax is messing with and recompiling modules and that indeed does seem to cause a lot of issues. |
| ||
| Kuron: No I didn't have the problem as I did not use it. One of the problems was, that FASM simply broke on source files larger than 64k. This needed a correct handling from BM side. You can only upgrade safely as long as the usage specs of FASM have not changed. As I don't know what they changed it could be that it works, but it may as well be that it breaks as BM is assuming 1.64 behavior, not 1.66 |
| ||
| My source files are around 80-120kb and it works fine with 1.66. |
| ||
| FASM is not a part of BlitzMax. That's not technically accurate. It would be more fair to say that FASM is not a part of BlitzMAX for Linux or MacOS. For Windows users FASM is the part of BlitzMAX that translates assembly sourcecode, as generated by BCC, into objectcode used by ld (the GNU linker). BlitzMAX canot function without it on a Windows OS, as the Windows OS does not come with a built-in assembler (like most Linux distros do) or an SDK (like MacOS does). Without FASM, BlitzMAX will not work. Period. Thus it is not only a part of, but an integral part of BlitzMAX (the product). |
| ||
| being as fasm is supplied with max and lives in its bin folder I'd maitain that changing it is very much customising blitzmax, if you want to be fair to any bug tester, before reporting *any* bugs to brl, you should veryfy the bug with the standard set of tools that are installed with blitzmax. |
| ||
| One of the problems was, that FASM simply broke on source files larger than 64k. I remember that problem, it was because BMax was using an outdated version of FASM that had a bug, and the problem was remedied by upgrading FASM. That's not technically accurate. It is a third-party tool that BMax utilizes. I'd maitain that changing it is very much customising blitzmax, You are not touching BMax, you are touching a third-party tool. If you don't know the difference in a bug being caused by Bmax itself, or a bug being caused by FASM, you probably shouldn't be using either. |
| ||
| bmax is a collection of tools... you probably shouldn't be using either. with an attitude like that, following your logic you probably shouldnt be using an internet connection |
| ||
| with an attitude like that, following your logic you probably shouldnt be using an internet connection Why, because I always keep my browser, firewall and av program up to date with the latest versions? |
| ||
| rude and ill informed |
   |