Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TF

40 views
Skip to first unread message

Paul Edwards

unread,
Nov 19, 2022, 2:23:04 PM11/19/22
to
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.

Alexei A. Frounze

unread,
Nov 19, 2022, 5:23:19 PM11/19/22
to
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

George Neuner

unread,
Nov 19, 2022, 5:38:21 PM11/19/22
to
INT 3 works on all x86 processors, but the response differs depending
on whether you are in real mode or protected mode.

wolfgang kern

unread,
Nov 21, 2022, 10:37:26 AM11/21/22
to
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

Paul Edwards

unread,
Nov 21, 2022, 5:37:53 PM11/21/22
to
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.

anti...@nospicedham.math.uni.wroc.pl

unread,
Nov 28, 2022, 4:08:37 PM11/28/22
to
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

Paul Edwards

unread,
Dec 4, 2022, 6:31:21 AM12/4/22
to
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.

George Neuner

unread,
Dec 5, 2022, 12:48:06 PM12/5/22
to
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

anti...@nospicedham.math.uni.wroc.pl

unread,
Dec 5, 2022, 2:22:42 PM12/5/22
to
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

Paul Edwards

unread,
Dec 5, 2022, 3:07:47 PM12/5/22
to
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.

0 new messages