Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #21781

Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers...

Show all headers | View raw

"AKE" <assadebrahim2000@gmail.com> wrote in message
news:250171bb-743a-4aa5-a510-825d4a7876e4@googlegroups.com...

> > The fact that you clobber and fail to restore ebp's value in
> > your snipped sample code seems to confirm that it's free.
> > Or, perhaps, that's a coding error?
> >
>
> How am I clobbering ebp?  cpuid doesn't affect ebp, I'm not
> affecting ebp, and other than that the rest is handled by
> Forth's assembler.  ebp may be in use or may not, but I don't
> think I'm clobbering it.  Since the snippet works, the only
> possible problem could be accidental success?

Sorry, I guess I looked at it a bit too quickly.  You're using
EBX, not EBP.

> > In a situation like this, PUSHA and POPA comes to mind,
> > especially for 16-bit and 32-bit code where they aren't
> > obsoleted instructions.  Also, you may want to use CLI
> > and STI.  The CLI and STI will prevent interrupts.  Although
> > uncommon, it is possible for interrupt routines to mess up
> > registers.
>
> Do I need to worry about interrupts if I'm working within
> Forth's assembler?  I would expect that the Forth application
> itself will take care of those details.  I'm just dropping down
> a level to give instructions, and as long as I restore any
> restricted registers I use, ought to be no difference between
> specifying using code ... end-code or :  ... ; , is that not
> right?

This is for x86 on Windows, yes? (i.e., Win32Forth)  Then,
maskable interrupts can interrupt your code at any time unless
they've been disabled by CLI or disabled by the processor
switching to an interrupt routine.  Maskable interrupts are
processor and software interrupts.  Non-maskable interrupts can
interrupt your code at any time too.  NMIs are usually hardware
interrupts.  NMIs can only be disabled via a special routine that
writes to CMOS non-volatile ram.  Writing to CMOS directly is
usually blocked by OSes operating in Protected Mode, such as
Windows or Linux.  I.e., you can't disable NMIs under most OSes.
You can disable NMIs if running in an unprotected OS like DOS in
Real Mode, probably CP/M too.  Now, I don't know what state
maskable and non-maskable interrupts are in for Win32Forth CODE
routine, but my assumption for both is that they're enabled.  Or,
the OS is toggling them as needed, i.e., might be, might not be,
but more likely enabled.

> > Of course, from your snipped sample code, it appears you found
> > a solution already.  You saved TOS simply by pushing ebx.  So,
> > I'm really not sure why you do something different for edx.
> > Can't you just push and pop edx also?
>
> I don't think a standard push or pop would work because if I
> push EDX before calling CPUID, then where would I pop it
> out to after the call?  The issue is that CPUID uses *all four*
> general purpose registers, so there's no 'spare' register to
> play the shell game.  The only way I could think to do it was
> to save edx into the unused part of the stack where I could then
> later fetch it from.  That's why edx is handled differently than
> ebx.
>
> I know it works (I usually try to find a solution, even it's
> ugly, before posting).  But having found a solution that seems
> a bit inelegant, I'm just wondering if there are better / more
> conventional ways of doing such things.

Sorry, ignore my earlier self ...  He seemed confused.  :-)

Fortunately, your code is correct.  I would use a CLI and STI
though.

Pushing EDX as I previously suggested would mean some stack
cleanup that would have to be done elsewhere or later.  If EBP,
ESP, ESI, EDI are all in use, you'll have to do what you did or
something very similar.

However, if EBP is free, you can save and restore EDX there,
er..., "play the shell game".  Can you find out?


I think you can shave _one_ instruction off the posted code ...
E.g., by moving the cpuid param N in EAX to EBX instead of pushing
it and popping it.  Of course, that ties up EBX which you're using
as a secondary stack pointer, so, you'd need to use another
register for your secondary stack pointer.  Fortunately, you have
two free registers at that point: EAX and ECX.  Also, you can then
reduce the alloted stack items from 4 to 3.

It seems DS must equal SS for Win32Forth.  Otherwise, your code
wouldn't work without a segment override when using EBX as a stack
pointer.  EBP and ESP default to SS, everything else to DS.


Rod Pemberton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-19 18:21 -0700
  Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-21 01:27 -0400
    Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-21 04:57 -0700
      Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-21 11:39 -0400
        Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-21 09:53 -0700
          Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-21 14:47 -0700
            Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 02:17 -0700
  Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Coos Haak <chforth@hccnet.nl> - 2013-04-21 17:34 +0200
    Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Coos Haak <chforth@hccnet.nl> - 2013-04-21 17:42 +0200
    Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-21 12:37 -0500
      Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-21 10:53 -0700
        Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-22 03:24 -0500
          Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 02:49 -0700
          Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-22 10:06 +0000
            Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-22 07:35 -0500
              Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-22 13:12 +0000
                Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-22 10:01 -0500
              Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 08:33 -0700
                Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-22 11:34 -0500
                Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-23 03:27 -0700
        Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-23 17:42 -0400
          Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-24 03:00 -0500
      Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-21 14:43 -0700
        Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 02:21 -0700
          Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 08:36 -0700
            Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... Alex McDonald <blog@rivadpm.com> - 2013-04-22 08:39 -0700
              Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-22 13:55 -0700
    Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... AKE <assadebrahim2000@gmail.com> - 2013-04-21 14:39 -0700
  Re: Stack Interface between x86 Assembler & Forth -- technique when running out of unprotected registers... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-04-21 21:00 +0000

csiph-web