I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL, it doesn't say that TF
also works for the 80386. INT 1 is complicated
instead.

So can I single-step an 80386 program?

It looks like x'cc' still works on an 80386, invoking
INT 3 (from my reading of RBIL).

Anyone know for sure?

Thanks. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 19 Nov 2022 11:09:42 -0800 (PST), Paul Edwards <mutazilah@nospicedham.gmail.com> wrote:

I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL, it doesn't say that TF
also works for the 80386. INT 1 is complicated
instead.

So can I single-step an 80386 program?

It looks like x'cc' still works on an 80386, invoking
INT 3 (from my reading of RBIL).

Anyone know for sure?

Thanks. Paul.

INT 3 works on all x86 processors, but the response differs depending
on whether you are in real mode or protected mode.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, November 19, 2022 at 11:23:04 AM UTC-8, Paul Edwards wrote:

I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL,

Why not read the intel or AMD documentation?

it doesn't say that TF
also works for the 80386.

It does, all the way through Pentium.

Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/11/2022 20:09, Paul Edwards wrote:

I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL, it doesn't say that TF
also works for the 80386. INT 1 is complicated
instead.

So can I single-step an 80386 program?

It looks like x'cc' still works on an 80386, invoking
INT 3 (from my reading of RBIL).

Anyone know for sure?

yes, CC work on all x86.
but any decent debugger use Traps instead:
a) by setting TF to single step one instruction w/o
the need for replace/insert a byte there.
b) by setting breakpoints [DATA or CODE or I/O] to
trap at occurrence (reason for debug-registers).
note: CC work different to the avoidable CD03.
__
wolfgang

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, November 21, 2022 at 11:37:26 PM UTC+8, wolfgang kern wrote:

On 19/11/2022 20:09, Paul Edwards wrote:

I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL, it doesn't say that TF
also works for the 80386. INT 1 is complicated
instead.

So can I single-step an 80386 program?

It looks like x'cc' still works on an 80386, invoking
INT 3 (from my reading of RBIL).

Anyone know for sure?

yes, CC work on all x86.
but any decent debugger use Traps instead:
a) by setting TF to single step one instruction w/o
the need for replace/insert a byte there.
b) by setting breakpoints [DATA or CODE or I/O] to
trap at occurrence (reason for debug-registers).
note: CC work different to the avoidable CD03.

Ok, thanks for that information.

I am interested in restricting myself to the same tools
that Tim Paterson had when creating the precursor
to MSDOS, with the difference that I am
doing 32-bit C programming instead of 16-bit
assembler programming, so when I debug at the
assembler level, it is almost all generated code.

BFN. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Edwards <mutazilah@nospicedham.gmail.com> wrote:

On Monday, November 21, 2022 at 11:37:26 PM UTC+8, wolfgang kern wrote:

On 19/11/2022 20:09, Paul Edwards wrote:

I have implemented TF (trap flag) for the 8086.

But when I looked up RBIL, it doesn't say that TF
also works for the 80386. INT 1 is complicated
instead.

So can I single-step an 80386 program?

It looks like x'cc' still works on an 80386, invoking
INT 3 (from my reading of RBIL).

Anyone know for sure?

yes, CC work on all x86.
but any decent debugger use Traps instead:
a) by setting TF to single step one instruction w/o
the need for replace/insert a byte there.
b) by setting breakpoints [DATA or CODE or I/O] to
trap at occurrence (reason for debug-registers).
note: CC work different to the avoidable CD03.

Ok, thanks for that information.

I am interested in restricting myself to the same tools
that Tim Paterson had when creating the precursor
to MSDOS, with the difference that I am
doing 32-bit C programming instead of 16-bit
assembler programming, so when I debug at the
assembler level, it is almost all generated code.

AFAIK CP-M was originally written in PL-M. Then, to improve
performance it was routine-by-routine rewritten in assembly.

Concerning debugging, integrated debug support is relatively
late, but there were external circuits that could single
step the processor, stop it on access to some specific
address and similar. High-end systems on this sort were
expensive, but established company could easily afford
them.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, November 29, 2022 at 5:08:37 AM UTC+8, anti...@nospicedham.math.uni.wroc.pl wrote:

Concerning debugging, integrated debug support is relatively
late, but there were external circuits that could single
step the processor, stop it on access to some specific
address and similar. High-end systems on this sort were
expensive, but established company could easily afford
them.

By "integrated debug" I assume you mean things like
the TF triggering an interrupt. That doesn't sound like
something complicated. Is there a reason for it to be
"relatively late"?

Thanks. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 4 Dec 2022 03:28:17 -0800 (PST), Paul Edwards <mutazilah@nospicedham.gmail.com> wrote:

On Tuesday, November 29, 2022 at 5:08:37 AM UTC+8, anti...@nospicedham.math.uni.wroc.pl wrote:

Concerning debugging, integrated debug support is relatively
late, but there were external circuits that could single
step the processor, stop it on access to some specific
address and similar. High-end systems on this sort were
expensive, but established company could easily afford
them.

By "integrated debug" I assume you mean things like
the TF triggering an interrupt. That doesn't sound like
something complicated. Is there a reason for it to be
"relatively late"?

Thanks. Paul.

I assume (perhaps wrongly) that the poster is referring to JTAG.

JTAG was developed originally in the 1980's, but it was not widespread
or really affordable to small developers really the mid/late 2000's.

Some people do consider ~15 years ago to be 'recent'.

George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Edwards <mutazilah@nospicedham.gmail.com> wrote:

On Tuesday, November 29, 2022 at 5:08:37 AM UTC+8, anti...@nospicedham.math.uni.wroc.pl wrote:

Concerning debugging, integrated debug support is relatively
late, but there were external circuits that could single
step the processor, stop it on access to some specific
address and similar. High-end systems on this sort were
expensive, but established company could easily afford
them.

By "integrated debug" I assume you mean things like
the TF triggering an interrupt. That doesn't sound like
something complicated. Is there a reason for it to be
"relatively late"?

One thing is debug registers. IIUC they were first in 386 and were
improved later. Now it seems that $0.4 processors contain
equivalent or better functionality. In 1975 typical
microprocessor needed external support chips, so there was
understandable resistance to putting something which was
not essential to running programs in processor chip.
And once we speak about external chips, folks who wanted
could add equivalent of debug registers using external
chips. Mass produces machines skipped debugging support
for cost reasons.

Another is view of "internal" state of "processor". In now
we have things like JTAG for this purpose. I early days
this was less important because signals that are internal
now were visible on processors bus and could be seen/manipulated
by external chips. Mainframes and minis typically contained
"operator console" which allowed view and modifications to
system bus and memory. Apparently home computers mostly
skipped this for cost reasons, but "developement systems"
had them.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, December 6, 2022 at 3:22:42 AM UTC+8, anti...@nospicedham.math.uni.wroc.pl wrote:

equivalent or better functionality. In 1975 typical
microprocessor needed external support chips, so there was
understandable resistance to putting something which was
not essential to running programs in processor chip.

But was this more of a philosophical thing? I think
even cheap CPUs in 1975 have flag registers, so
adding a TF to trigger int 1 seems like not a lot of
effort. Would it have increased the price of a CPU
by more than 0.1%?

And why does the 8086 have that when other processors
didn't for whatever reason?

And once we speak about external chips, folks who wanted
could add equivalent of debug registers using external
chips. Mass produces machines skipped debugging support
for cost reasons.

And this is the problem I would like to avoid. At least with
the benefit of hindsight, we know that programmers are
going to lose decent debug support if you don't put the
basic (breakpoints and TF) debug support into the CPU
itself.

BTW, I only learnt about this INT 1 and 3 mechanism
about a year ago.

I can't remember if I mentioned it, but PDOS/86 and
PDOS/386 (from pdos.org) now support a "monitor"
that uses those two facilities.

BFN. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)