From: muta...@gmail.com   
      
   On Monday, March 20, 2023 at 11:54:27 PM UTC+8, wolfgang kern wrote:   
      
   > On 20/03/2023 14:51, muta...@gmail.com wrote:    
   > > On Monday, March 20, 2023 at 8:54:21 PM UTC+8, wolfgang kern 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?   
      
   > >> and what's wrong with call/ret in long mode    
   > >>    
   > >> FF D0 .... C3    
   > >> 48 FF D0 .... C3    
   > >    
   > > 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?   
      
   > >> 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.   
      
   > 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).   
      
   It is unclear to me whether I can get the C compiler   
   to auto-generate the glue.   
      
   Or whether there is some other technique.   
      
   > > 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?   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)