From Newsgroup: comp.arch

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h


#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.
This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available. It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

My guess would be that many kernel hackers would be overjoyed at
this functionality.

Comments?

(I did get the second idea from somebody who happens to work as
a Linux kernel hacker at the moment, and who would be overjoyed :-)
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 5/19/2026 2:02 PM, Thomas Koenig wrote:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Not nesserally related, but and fwiw, this reminds me of emulating cpu
local data from user land using thread affinities. ;^) One thread per cpu/core/hyperthread with its affinity mask for it, _cross your fingers_
and hope they are _honored_ by the os, and it worked. But it was a
massive hack...

On testing, it seemed to hold up. But, its NOT documented to do so from
user land. So, experiment fun land is shall stay.

Each thread would be pinned to a CPU, and use its thread local storage
as its "pseudo" per-"CPU" storage... I still used atomic loads and
stores even though it did not matter... If the OS would tell my affinity
masks to go to hell and back... well, not CPU local any longer! Ouch. ;^o

For some reason in my emulated per CPU data, I used std::atomic for
thread local data. That is not ideal unless your thread local data can
be accessed by something else. Fwiw, I have systems where the per-thread locals can be accessed by another thread(s). Example... A polling thread
that has a list of registered threads, then things go into single
producer single consumer type sync.

Also, another point where per-thread data can be accessed by another
thread. Say thread A allocates something on it per thread stack. Passes
it to another thread B that can deallocate it. Well, thread B notices
that the memory is not its own and passes it back to thread A via a
multi producer single consumer queue. Something akin to:
___________
pool* p = (pool*)((uintptr_t)ptr & ~(BLOCK_SIZE - 1));
if (p == my_pool_ptr) {
// local
} else {
// remote - and p IS the target thread's pool,
// so you already have everything you need!
}
___________


[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

It seems to me that rarely is SW in a position to disable all interrupts*,
and much more likely to disable (ignore for a while) interrupt below a
certain priority. (*) NMI as an interrupt and Machine Check as an exception
are more important than the SW critical section at hand.

Secondarily; HyperVisor should be in a position to take exceptions from
GuestOS just like GuestOS takes exceptions on behalf of User applications.
So, while GuestOS ISR can page fault as long as the PF is handled by
HyperVisor and GuestOS ISR does not see any of it happening. We need to
quit thinking about systems with only 2 levels of privilege. --------------------------
My 66000 maintains a priority for CPUs, each thread has its own priority
and each layer in the SW stack has its own priority. This allows one to disallow priorities at lower levels while allowing priorities at higher
levels to still interrupt. SW knows about the priority structure, and
arranges that higher priority things do not damage lower priority data.
{to hand waving accuracy}.

A thread with priority can directly access its priority in a single instruction; Header Register HR instruction--which has 3 variants:
Read Control Register, Write control register, and Exchange control
register.

When transiting the privilege hierarchy, no maintenance of priority
is required--it is done auto-magically--only when SW wants something
outside of it normal operating conditions does SW have to expend any instructions in maintaining priority.

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.

This is the underlying premise of My 66000 Exotic Synchronization Mechanism--sometimes you don't want to retry the ATOMIC sequence,
instead, you want to take a fresh look at the concurrent data
structure as it is now {not how it was 1 ms ago}. To the extent
that the OS can plan the ESM-game; it's all FREE.

This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available.

Kernel could do exactly this same thing with HyperVisor {and then
HV can do the same thing with Secure Monitor.}

Kernel doing this to itself is about as difficult as allowing a
user (application) to take exceptions for itself--which is a non
simple state stacking and unwinding problem (not unlike Delayed
Procedure Calls and the linux variant softIRQ).

Longjump() does not play well with this unwinding...

It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

HRX R9,priority,#16 // block lower priority interrupts
...
HRW priority,R9 // back to where we were

Without length limitations.

Would exceptions be allowed during interrupt disablement ??
How does interrupt priority play into taking/ignoring-for-now ?

My guess would be that many kernel hackers would be overjoyed at
this functionality.

Comments?

(I did get the second idea from somebody who happens to work as
a Linux kernel hacker at the moment, and who would be overjoyed :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


MitchAlsup <user5857@newsgrouper.org.invalid> posted:

Thomas Koenig <tkoenig@netcologne.de> posted:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

It seems to me that rarely is SW in a position to disable all interrupts*, and much more likely to disable (ignore for a while) interrupt below a certain priority. (*) NMI as an interrupt and Machine Check as an exception are more important than the SW critical section at hand.

Secondarily; HyperVisor should be in a position to take exceptions from GuestOS just like GuestOS takes exceptions on behalf of User applications. So, while GuestOS ISR can page fault as long as the PF is handled by HyperVisor and GuestOS ISR does not see any of it happening. We need to
quit thinking about systems with only 2 levels of privilege. --------------------------
My 66000 maintains a priority for CPUs, each thread has its own priority
and each layer in the SW stack has its own priority. This allows one to disallow priorities at lower levels while allowing priorities at higher levels to still interrupt. SW knows about the priority structure, and arranges that higher priority things do not damage lower priority data.
{to hand waving accuracy}.

A thread with priority can directly access its priority in a single instruction; Header Register HR instruction--which has 3 variants:
Read Control Register, Write control register, and Exchange control register.

When transiting the privilege hierarchy, no maintenance of priority
is required--it is done auto-magically--only when SW wants something
outside of it normal operating conditions does SW have to expend any instructions in maintaining priority.

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.

This is the underlying premise of My 66000 Exotic Synchronization Mechanism--sometimes you don't want to retry the ATOMIC sequence,
instead, you want to take a fresh look at the concurrent data
structure as it is now {not how it was 1 ms ago}. To the extent
that the OS can plan the ESM-game; it's all FREE.

This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available.

Kernel could do exactly this same thing with HyperVisor {and then
HV can do the same thing with Secure Monitor.}

Kernel doing this to itself is about as difficult as allowing a
user (application) to take exceptions for itself--which is a non
simple state stacking and unwinding problem (not unlike Delayed
Procedure Calls and the linux variant softIRQ).

Longjump() does not play well with this unwinding...

It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

HRX R9,priority,#16 // block lower priority interrupts
...
HRW priority,R9 // back to where we were

Without length limitations.

It also occurs to me that GuestOS SW could DPC or softIRQ to a
priority level above that which they are now running to do some
tricky-OS-work, too. {As far as I can see DPC can enqueue work
above the current priority level, and figure out this it should
get-to-it prior to returning from DPC().

Would exceptions be allowed during interrupt disablement ??
How does interrupt priority play into taking/ignoring-for-now ?

My guess would be that many kernel hackers would be overjoyed at
this functionality.

Comments?

(I did get the second idea from somebody who happens to work as
a Linux kernel hacker at the moment, and who would be overjoyed :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 19/05/2026 23:02, Thomas Koenig wrote:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

It would surely be a minor matter to implement such a pre-emption
counter as a hardware register, along with "increment" and "decrement" instructions (possibly just handled as writes to a different special
register, rather than unique instructions).

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.
This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available. It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

My guess would be that many kernel hackers would be overjoyed at
this functionality.

Comments?

(I did get the second idea from somebody who happens to work as
a Linux kernel hacker at the moment, and who would be overjoyed :-)

I don't know much detail of the internals of Linux, and my work focuses
on microcontrollers rather than "big" processors. In particular, I
rarely deal with multiple cores. But there's a certain overlap between
the lowest levels of kernel programming and bare-metal or RTOS
programming on microcontrollers.

I have long thought that something akin to your "preempt #6" instruction
would be hugely useful in microcontrollers. For single-core systems, it
would make simulating atomic operations significantly more efficient.
And being time limited, it could be available at the user level rather
than needing kernel or OS privileges (obviously the hardware would have
to guarantee interrupts are seen between successive "preempt" instructions).

However, you would probably have to have limitations on what
instructions could be executed within a "preempt" sequence. And it
would be more complicated on bigger systems - a simple memory access
could trigger a page fault, and that would lead to complications.

For SMP or other multi-core systems, this mechanism would not be enough
on its own, but it could surely help the efficiency of some things.

In the few multi-core microcontrollers I have used, there has always
been a dedicated hardware block for semaphores, locks, or some kind of inter-cpu messaging that is vastly more efficient than general
mechanisms. I realise the scaling requirements for large multi-core processors is a lot more complicated, but there is surely scope for more hardware assistance for the deepest parts of the kernel.




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h


#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

It seems to me that rarely is SW in a position to disable all interrupts*, and much more likely to disable (ignore for a while) interrupt below a certain priority. (*) NMI as an interrupt and Machine Check as an exception are more important than the SW critical section at hand.

Agreed. If the result of an interrupt is a kernel panic or a reboot
of the device, then the integrity of a lock becomes secondary.

Secondarily; HyperVisor should be in a position to take exceptions from GuestOS just like GuestOS takes exceptions on behalf of User applications.

So, Linux (for example) should not be able to run on bare metal?
I think that many people would disagree, Linus Torvalds included.

[...]

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.

This is the underlying premise of My 66000 Exotic Synchronization Mechanism--sometimes you don't want to retry the ATOMIC sequence,
instead, you want to take a fresh look at the concurrent data
structure as it is now {not how it was 1 ms ago}. To the extent
that the OS can plan the ESM-game; it's all FREE.

This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available.

Kernel could do exactly this same thing with HyperVisor {and then
HV can do the same thing with Secure Monitor.}

Again, this requires multiple levels.

Kernel doing this to itself is about as difficult as allowing a
user (application) to take exceptions for itself--which is a non
simple state stacking and unwinding problem (not unlike Delayed
Procedure Calls and the linux variant softIRQ).

rseq works well, but does need a few lines of assembly (and more
because of the setup). Basically, you hand the kernel an address
via a system call that, if the process is interrupted in a certain
sequence, then the return address is changed. That sequence has
to follow certain rules; especially, it can only introduce visible
state (for example a pointer store) in the last instruction.

It is then the user's resposibility to handle that case responsibly.

I'm not saying that this is the easiest thing in the world to
program for, but it works well

Longjump() does not play well with this unwinding...

It should have no influence.

It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

HRX R9,priority,#16 // block lower priority interrupts
...
HRW priority,R9 // back to where we were

Without length limitations.

That would not play well with the Linux model, which does not depend
on interrupt levels and can get by with a single one.

Would exceptions be allowed during interrupt disablement ??

Yes.

How does interrupt priority play into taking/ignoring-for-now ?

In the Linux kernel model, interrupts can be disabled completely
or not at all. They are only disabled in the hard IRQ handlers,
which then hand off work to the soft IRQ handlers, which can
be peempted.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 2026-05-19 5:02 p.m., Thomas Koenig wrote:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.
This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available. It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

I called this the 'atom' modifier for Q+. Disables interrupts except for
NMI for a specified number of instructions. One gotcha is that it can
only apply to instruction groups. So exactly how many instruction are
executed with interrupts disabled depends on the mix. The number is a
minimum. It is meant only for a small number of instructions.

There is also an instruction to branch if an interrupt is present.

which would schedule all interrupts only after the next six
instructions (with severe limits on the number ant types
instructions as not to lock up the system).

My guess would be that many kernel hackers would be overjoyed at
this functionality.

Comments?

(I did get the second idea from somebody who happens to work as
a Linux kernel hacker at the moment, and who would be overjoyed :-)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being
interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h


#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

It seems to me that rarely is SW in a position to disable all interrupts*, and much more likely to disable (ignore for a while) interrupt below a certain priority. (*) NMI as an interrupt and Machine Check as an exception are more important than the SW critical section at hand.

Agreed. If the result of an interrupt is a kernel panic or a reboot
of the device, then the integrity of a lock becomes secondary.

Secondarily; HyperVisor should be in a position to take exceptions from GuestOS just like GuestOS takes exceptions on behalf of User applications.

So, Linux (for example) should not be able to run on bare metal?
I think that many people would disagree, Linus Torvalds included.

Not my stated nor implied intent.

GuestOS is not in a position to take a page fault in ISR because GuestOS
page tables say page is present in DRAM. HyperVisor page tables (nested)
can say the page is not present in memory, thus GuestOS can run on bare
HW, and under HV.

It is because GuestOS sets is ISR pages to present that it (GuestOS)
is not in a position do deal with an event it thinks cannot happen !!
The HV made it happen, thus HV has to be in a position to fix it if it
does happen.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Robert Finch <robfi680@gmail.com> posted:

On 2026-05-19 5:02 p.m., Thomas Koenig wrote:

In a multithreaded, preemptible kernel, there is a need for keeping
out interrupts from certain sections to prevent them from being interrupted. The main mechanism in Linux, for example, can be
found in

https://github.com/torvalds/linux/blob/master/include/linux/preempt.h

#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)

The counters are kept CPU-local, which can be done relatively easy
on x86 with segment registers. On aarch64, some atomics are needed.

Could this be improved, and could hardware help?

In userland, Linux has restartable sequences. Basically, you
tell the kernel that, if a certain code sequence is interrupted,
it should return to a different address than the one it came from.
This code can then recover, retry or whatever. For this, userland
has to hand a data structure to the kernel describing things.
Some details at https://lwn.net/Articles/883104/ .

But the kernel has no such mechanism available. It could be
possible and useful for the hardware to provide a instruction
modifier

rseq r10,#6

which would be an indirect jump to r10 if there was a hardware
interrupt in the next six instructions.

An alternative could be an instruction modifier

preempt #6

I called this the 'atom' modifier for Q+. Disables interrupts except for
NMI for a specified number of instructions. One gotcha is that it can
only apply to instruction groups. So exactly how many instruction are executed with interrupts disabled depends on the mix. The number is a minimum. It is meant only for a small number of instructions.

In My 66000, the compiler puts the instruction-count in the then-clause
and else-clause. Over in the assembler, after the instruction sizes
have been determined, those sizes are changed into word-counts--just like
it determines the offsets for branch labels from the branch instruction.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

In My 66000, the compiler puts the instruction-count in the then-clause
and else-clause. Over in the assembler, after the instruction sizes
have been determined, those sizes are changed into word-counts--just like
it determines the offsets for branch labels from the branch instruction.

That is new to me. The current version of the assembler certainly
does not do so, and we discussed this previously.

When did that change?
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

In My 66000, the compiler puts the instruction-count in the then-clause
and else-clause. Over in the assembler, after the instruction sizes
have been determined, those sizes are changed into word-counts--just like it determines the offsets for branch labels from the branch instruction.

That is new to me.

We talked about this 2-3 months ago. I remember Brian bringing this up.

The current version of the assembler certainly
does not do so, and we discussed this previously.

When did that change?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

In My 66000, the compiler puts the instruction-count in the then-clause
and else-clause. Over in the assembler, after the instruction sizes
have been determined, those sizes are changed into word-counts--just like >> > it determines the offsets for branch labels from the branch instruction. >>

That is new to me.

We talked about this 2-3 months ago. I remember Brian bringing this up.

Maybe I didn't pay close enough attention at the time... but in
the most recent version of the ISA, it is not clearly specified.

Not sure how to implement this in the compiler/assembler combination
in the presence of instructions whose length can only be determined
by the assembler.

The disassembler needs to re-convert the instruction bytes into
number of instructions (if the TTFF... notation should be kept),
which is impossible without lookahead, and the disassembler cannot
do this (and will not).

I think this needs further discussion.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

In My 66000, the compiler puts the instruction-count in the then-clause >> > and else-clause. Over in the assembler, after the instruction sizes
have been determined, those sizes are changed into word-counts--just like
it determines the offsets for branch labels from the branch instruction. >>

That is new to me.

We talked about this 2-3 months ago. I remember Brian bringing this up.

Maybe I didn't pay close enough attention at the time... but in
the most recent version of the ISA, it is not clearly specified.

Not sure how to implement this in the compiler/assembler combination
in the presence of instructions whose length can only be determined
by the assembler.

The disassembler needs to re-convert the instruction bytes into
number of instructions (if the TTFF... notation should be kept),
which is impossible without lookahead, and the disassembler cannot
do this (and will not).

Disassembler has binary then-bits and else-bits from which TTTFFF can be directly emitted.

I think this needs further discussion.

Obviously.

--- Synchronet 3.22a-Linux NewsLink 1.2