FPC32 (with db66/db67) in DOS lazarus / 68-Other OS ---------------------------------------------------------------------- microxa · 2020-10-09 12:29 Hi! for me FPC is more 'asm' than 'hll', but for fun: I got an excellent result, using just the patched 32-bit FPC code generator (for Win32 target). Then just post-processing Win32-PE to normalize in DOS exe. Of course, the minimal/dummy RTL (system/sysinit/fpintres)  is used. Funny, but incredibly wild, x86_16 machine code (for 386+) works very well! tested under dosbox(real mode)/ntvdm(v86). despite some restrictions, are obtained rather complicated program: http://imgsharing.ru/94576286.png Thanks for the powerful supercompiler! it was needed for a long time.. I'm happy again, sometimes doing programming! p.s. may be interesing: common changes (aasmcpu.pas) for functions taicpu.calcsize/taicpu.GenCode Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     function taicpu.calcsize(p:PInsEntry):shortint;      var        i,data:longint;        codes : pchar;      ...        exists_prefix_F2 := false;        exists_prefix_F3 := false;     { ...  }        data:=pInteger(codes)^ and $FFFFFF;        {fix  call [procedure call mem??] }        if data = $FF01D5 then inc(len,2) else begin        data:=0;         for i:=0 to ops-1 do data:=data or oper[i]^.ot;      data := data and $0E000004; //mem®32         if data = $00000004 then inc(len) else        if data = $0E000000 then inc(len) else      if data = $0E000004 then inc(len,2) else        begin           c:=ord(codes[1]);data:=pInteger(codes)^ and $FFFFFF;           case data of             $00C301, //retn            $00C901, //leave          $6001D5, //pushad            $6101D5, //popad            $CF01D5: //iretd                inc(len);           end;        end;  { original code }         repeat          c:=ord(codes^);          inc(codes); ---------------------------------------------------------------------- PascalDragon · 2020-10-09 13:46 Quote from: microxa on October 09, 2020, 02:29:21 pmI got an excellent result, using just the patched 32-bit FPC code generator (for Win32 target). Then just post-processing Win32-PE to normalize in DOS exe. Of course, the minimal/dummy RTL (system/sysinit/fpintres)  is used. Funny, but incredibly wild, x86_16 machine code (for 386+) works very well! tested under dosbox(real mode)/ntvdm(v86). While that is an interesting experiment, you are aware that FPC fully supports 16-bit x86 through the i8086 target? ---------------------------------------------------------------------- microxa · 2020-10-10 22:13 Hello PascalDragon. yes, I know that .. but there isn't exactly a 32 bit code generator. By the way, version 3.2.0 has been successfully implemented for 16-bit mode, but version 3.3.1 unfortunately falls from memory burnout. But nevertheless, it was possible to transfer part of the optimizer modules (aoptx86, etc.) from version 3.3.1 to 3.2 I like this quest .. ---------------------------------------------------------------------- lucamar · 2020-10-10 23:00 Maybe I'm being dense (probably )  but I'll ask: what's the point? I mean, FPC by itself already does generate 32 bits, protected-mode apps in DOS, and there is already a 16-bit generator so ... what's is "special" about what you're doing? I'm really interested: we have a few apps working on DOS, both FP 32 bits and TP 16 bits (which we'll convert to 16 bit FP as soon as we can and the 16 bits compiler becomes fully stable and tested). It would be nice to know whatever alternatives there are out there. ---------------------------------------------------------------------- microxa · 2020-10-11 00:27 This is just an instrumental feature, implemented simply as helloworld. The only alternative - is manual assembly. ---------------------------------------------------------------------- microxa · 2020-10-12 04:25 В v331, a strange leak occurs when compiling files of medium/big size and if the optimization is -Op80386-OpPENTIUM. (i was not attentive to fpc.cfg) So this is not very critical. Optimization has very improved. And yes, 16bitted matrix has me... Ok! >>what's is "special" about what you're doing? dear, lucamar too many "special & somspecial" for the x86 architecture. What can be done from the moment of launching in dos, iterating 32-bit code in real mode? This remains to be analyzed. ---------------------------------------------------------------------- marcov · 2020-10-12 05:56 Doesn't the i8086 backend use 386 instructions for longint when properly instructed ? It seems more straightforward to work towards more 32-bit usage with i8086 than within the i386 backend, since that has the correct memory model. If it is not about the memory model, one could simply use go32v2 target. ---------------------------------------------------------------------- microxa · 2020-10-12 15:24 Ок.. I am in no way detracting from the merits of other instruments. Conceptually, i8086 codegen engine use traditional/canonical, segment- oriented model code & data distribution. This, may be, good for i8086-i80286. Go32 highly advanced DPMI framework. but.. of course, in my case, the Win32/flat model programming approach is more used  (more skills, experience, habits).. And, perhaps "WDOSX" was the reason that made me think about "db66 / db67 powered code". At one time, under this mini-win32 environment, it was possible to successfully run FPC (2.2), but the main, small kernel, it was executed in a 16-bit code selector. The same can be said about the HX-DOS extender. Due to the increased complexity, many things remained abandoned and not implemented - since it took a lot of assembler art, and constant delving into unnecessary details. And only Pascal always came to the rescue! And as we can see, even where it is not accepted, in no mainstream HLL - "Intel opcode powered db.. " .. oh you know :-D ---------------------------------------------------------------------- lucamar · 2020-10-12 16:27 I guess you were one of those using "unreal" mode and 4Gb segments, huh? ---------------------------------------------------------------------- microxa · 2020-10-12 20:17 un(big)real, exec above 1mb boundary, multithreading.. Yes, it's not that hard, it was harder to figure out what to do next).. but, something was used, then in the win32(under kernel mode). DOS has a legacy of unique examples that still serve as sources of inspiration. Which is very precious! It's amazing that your project still supports this.. It will not be more surprising if "holy sweet real mode x86" does not remain in the new generations of x86 , But there is (ex)VEX, x64, and FPC, which understands this better than an assembler guru))) (I still do not understand where the code generator is hidden there, and it is very valuable, to me, that post processing was stacking in GenCode)