From: nowhere@never.at   
      
   On 21/03/2023 01:10, muta...@gmail.com wrote:   
      
   >>>>> I assume the syntax would be:   
   >>>>>   
   >>>>> mov eax, after   
   >>>>> mov [esp + 0], eax   
   >>>>> mov eax, sub   
   >>>>> jmp *eax   
   >>>>> after:   
   >>>>>   
   >>>>> sub:   
   >>>>> ...   
   >>>>> mov eax, [esp + 0]   
   >>>>> jmp *eax   
   >>>> this may not work as you expect.   
   >>>   
   >>> Why not?   
      
   >> you think this stack position is as a save place to hold values ?   
   >> IRQs (timer/kbd/mouse/...) may use it. And that's why PUSH/POP were   
   >> implemented :)   
   >   
   > Don't I just need to subtract something from the sp   
   > before doing the manipulations?   
   >   
   >> mov eax,[rsp+0] act as MOVZXD rax,[rsp]   
   >   
   > Is that a problem?   
      
   no problem if you don't need the high part of RAX   
      
   >>> I want my 32-bit code to work on both an 80386 and on   
   >>> an x64 in long mode.   
      
   >> Now this is a really bad idea, because this looses a lot of features   
   >> from both modes and will end up in weird detours for no reason.   
      
   > This is all generated code. I don't need a lot of features,   
   > I just need sufficient features for an arbitrary program.   
      
   >> The difference between this two modes is just too large and for switch   
   >> demands all options were designed and implemented..   
      
   > Are you sure it is too large for my purposes?   
      
   fine if your purpose is just a hobby gadget rather than a serious OS.   
      
   >>>> if you like to run 32 bit code within 64 bit environment then just   
   >>>> switch back and forth between this two modes.   
   >>>> Oh, you don't have a BIOS/UEFI function for such ? write your own.   
      
   >>> I don't want to write my own. I want to follow the EFI   
   >>> spec and have carefully-generated assembler that can   
   >>> tolerate running on both 32 and 64-bit environments.   
      
   >> You cant build your own OS by "don't want to write..."   
      
   > Yes I can. As per the above design.   
   > For the last almost 30 years I have successfully avoided   
   > having to write hard disk drivers too.   
      
   I see, and by using BIOS you can avoid to write all HW-drivers like KBD,   
   mice,RTCL,PIT,PIC,mem-alloc,screen control/text/graphic and sound...   
   I wont call such a 'rely on BIOS only' thing an OS.   
      
   >> and you wont follow UEFI boot specs by using 32-bit code.   
   > The BOOTX64.EFI will be 64-bit.   
   > The 32-bit code will still be technically valid 64-bit code.   
      
   > I may need some assembler to glue above two things   
   > together, for when the 32-bit code calls a 64-bit API   
   > exposed by the pseudo-bios (bootx64.efi).   
      
   read CPU manuals about hw-implemented task-switches ...   
      
   > It is unclear to me whether I can get the C compiler   
   > to auto-generate the glue.   
   >   
   > Or whether there is some other technique.   
      
   sure there is: the NON-C approach!   
      
   >>> I'm not sure there is actually a way to write my own   
   >>> even outside of the EFI spec. Don't I need access to   
   >>> the GDT or whatever which can't be manipulated until   
   >>> I exit boot services?   
      
   >> once the GDT is proper setup to cover LM64 and PM32 needs, the switches   
   >> don't need to alter GDT entries, only descriptors have to change.   
      
   > And? Does the EFI spec provide a way to do all of that, without   
   > exiting boot services?   
      
   check on it, read GDT entries may not be a problem for an OS ? :)   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)