Jim Henderson wrote:
> But it wouldn't be hard to write a function that does the low-level 
> stuff, either, 

Unless you're going to do something like write into a char[], then cast 
the char[] to a function pointer, I'm pretty sure you can't invoke 
arbitrary machine code from C. :-) *Somewhere* there's assembler.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sat, 01 Dec 2007 19:09:21 -0800, Darren New wrote:

> Jim Henderson wrote:
>> But it wouldn't be hard to write a function that does the low-level
>> stuff, either,
> 
> Unless you're going to do something like write into a char[], then cast
> the char[] to a function pointer, I'm pretty sure you can't invoke
> arbitrary machine code from C. :-) *Somewhere* there's assembler.

I'd think that'd be true for pretty much any language, though - even Ada.

But I was thinking along the lines of what you said.

Jim

Post a reply to this message

Jim Henderson wrote:
> I'd think that'd be true for pretty much any language, though - even Ada.

Actually, no. It has an explicit construct for catching interrupts by 
invoking a routine. (The routine would be in what Java calls a 
synchronized class.)  You specify the priority of the interrupt, and 
which interrupt it is, and all that.  I am not sure you can actually say 
what registers wind up in which arguments within the language, granted. :-)

> But I was thinking along the lines of what you said.

Yeah, but that's still not actually C. That just happens to be knowing 
what your particular C compiler outputs for a program that has no 
semantics in C. It's really not C any more than inline assembler is. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sun, 02 Dec 2007 12:07:50 -0800, Darren New wrote:

> Jim Henderson wrote:
>> I'd think that'd be true for pretty much any language, though - even
>> Ada.
> 
> Actually, no. It has an explicit construct for catching interrupts by
> invoking a routine. (The routine would be in what Java calls a
> synchronized class.)  You specify the priority of the interrupt, and
> which interrupt it is, and all that.  I am not sure you can actually say
> what registers wind up in which arguments within the language, granted.
> :-)

See, to me, that's not much different than a function call - just a very 
directly implemented function call. :-)

But probably closer to invoking, say, INT21 than you would do from C 
using inline - though the generated code by the compiler would probably 
be very close.

>> But I was thinking along the lines of what you said.
> 
> Yeah, but that's still not actually C. That just happens to be knowing
> what your particular C compiler outputs for a program that has no
> semantics in C. It's really not C any more than inline assembler is. :-)

True; but I'm guessing you're talking at a level in the language/compiler 
that I'm much less familiar with - in the end, you end up with machine 
code no matter what you do, since that's all the machine actually 
understands.

Jim

Post a reply to this message

Jim Henderson wrote:
> See, to me, that's not much different than a function call - just a very 
> directly implemented function call. :-)

Well, yah, except you say "invoke this function when you get that 
interrupt", and you don't set up the interrupt table yourself, and you 
don't have to deal with turning interrupts on and off, generating 
special return instructions, managing the priorities, etc.

Kind of the difference between having threading or dynamic loading in a 
language, and invoking an OS-specific library for it. Functionally 
pretty similar, except you only have to learn it once and it generally 
works out better/easier to use.

> But probably closer to invoking, say, INT21 than you would do from C 
> using inline - though the generated code by the compiler would probably 
> be very close.

I'm talking about handling interrupts, like in the kernel or a device 
driver, rather than generating interrupts. If that's the confusion... :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sun, 02 Dec 2007 12:53:54 -0800, Darren New wrote:

> Jim Henderson wrote:
>> See, to me, that's not much different than a function call - just a
>> very directly implemented function call. :-)
> 
> Well, yah, except you say "invoke this function when you get that
> interrupt", and you don't set up the interrupt table yourself, and you
> don't have to deal with turning interrupts on and off, generating
> special return instructions, managing the priorities, etc.
> 
> Kind of the difference between having threading or dynamic loading in a
> language, and invoking an OS-specific library for it. Functionally
> pretty similar, except you only have to learn it once and it generally
> works out better/easier to use.
> 
>> But probably closer to invoking, say, INT21 than you would do from C
>> using inline - though the generated code by the compiler would probably
>> be very close.
> 
> I'm talking about handling interrupts, like in the kernel or a device
> driver, rather than generating interrupts. If that's the confusion...
> :-)

Ahhhh, I was thinking you/we were talking about calling interrupts - 
chaining interrupts is definitely something different.  I think back in 
the early 90's I wrote an interrupt chain in C, and you're right, it 
wasn't very straighforward.  I'd have to pull out a couple of my old 
books on interrupt programming to remember how I did it.

I know I did do it, though, because there were some undocumented DOS 
interrupts that I used for doing various tricky things in NetWare login 
scripts in the 3.x days - things like changing the master DOS environment 
table from within a DOS login script; I'm fairly sure I didn't write them 
in assembler, but it has been 20+ years since I did that, so maybe I did 
do that.

Jim

Post a reply to this message

Jim Henderson wrote:
> Ahhhh, I was thinking you/we were talking about calling interrupts - 

Now you got me curious, and I pulled down my Ada textbook.

Turns out the interrupt procedures don't have arguments (other than, of 
course, knowing which interrupt it was). I suppose that makes sense at a 
machine level, except for the software interrupts.

You can have declarations like
   for X'address use A;
to make X get allocated at the address represented by A. Works for code 
or data, meaning you don't have to do anything funky to put code in a 
particular ROM address, for example.

You can, of course, say
   for X'address use Y'address;
to alias X and Y together, if they are, say, different types for the 
same hardware or something.

(Note: X'Y is the syntax for accessing compile-time property Y of object 
X, so in Ada, it would be something like X'size instead of sizeof(x))

There's also decomposed addresses, letting you extract the segment and 
offset from a segmented address.

There's also Atomic and Volatile declarations (with the obvious 
semantics), the 'alignment attribute, the 'bit_order attribute (to 
control the order of allocations that C would use for bitfields in 
structs), the 'storage_size expression that lets you overallocate 
storage for an object (so you can, for example, allocate one block of 
flash to a particular set of routines or data).

You can set the dispatch policies (like whether tasks are FIFO within 
the priorities, or whether they run to completion, or whatever), and 
(hey Warp) the 'Immediate_Reclamation attribute, which means storage for 
a declared object is reclaimed as soon as the object ceases to exist. ;-)

Given all that, it still can be a pretty annoying language to use.

> I'm fairly sure I didn't write them 
> in assembler, but it has been 20+ years since I did that, so maybe I did 
> do that.

I'm guessing you did the same sort of thing that old BASIC programs did, 
which was machine code in DATA statements poked into memory and then 
executed.  If your compiler translates integers to addresses in a 
straightforward way, it would be pretty easy to do that in C.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

Darren New wrote:

> At the lowest lowest level, I'm pretty sure the libraries load up 
> arguments into registers and execute an INT instruction, which is a 
> "software interrupt", aka a trap, which causes a branch to an address 
> loaded into a specific area of memory. I.e., just like handling an 
> interrupt, or just like branching to a jump table in a library, except 
> that you get privilege bits flipped around.
> 
> I don't know of any modern multiuser OS that doesn't use that technique 
> to get into the kernel, as it's pretty much the only way to bypass 
> memory and execution permissions in a controlled way.

OK, that's what I wanted to know...

(PS. Is there more than one interrupt level available? Or does it decide 
which routine to call based on some other parameter?)

Post a reply to this message

Invisible nous apporta ses lumieres en ce 2007/12/03 04:46:
> Darren New wrote:
> 
>> At the lowest lowest level, I'm pretty sure the libraries load up 
>> arguments into registers and execute an INT instruction, which is a 
>> "software interrupt", aka a trap, which causes a branch to an address 
>> loaded into a specific area of memory. I.e., just like handling an 
>> interrupt, or just like branching to a jump table in a library, except 
>> that you get privilege bits flipped around.
>>
>> I don't know of any modern multiuser OS that doesn't use that 
>> technique to get into the kernel, as it's pretty much the only way to 
>> bypass memory and execution permissions in a controlled way.
> 
> OK, that's what I wanted to know...
> 
> (PS. Is there more than one interrupt level available? Or does it decide 
> which routine to call based on some other parameter?)
If my memory is good. On the 8086, there where about 256 programable software 
interupts available to programmers. Interupts 0 to 15 are special periferals 
interupts. There where also some hardware interupts, but I don't know how many. 
The "Reset" switch triggers one of them.

-- 
Alain
-------------------------------------------------
   I'm so ugly I stuck my head out the window and got arrested for Mooning.
   	Rodney Dangerfield

Post a reply to this message

On Sun, 02 Dec 2007 17:16:49 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Ahhhh, I was thinking you/we were talking about calling interrupts -
> 
> Now you got me curious, and I pulled down my Ada textbook.

[...]

> Given all that, it still can be a pretty annoying language to use.

Yep, on that point we agree. :-)  I did always think the exception 
handling being able to handle things at the hardware interrupt level was 
cool in Ada.  Just not cool enough to justify the memory usage of 
machines 20 years ago (which is nearly when I learned it, doesn't seem 
possible it was almost that long ago).

>> I'm fairly sure I didn't write them
>> in assembler, but it has been 20+ years since I did that, so maybe I
>> did do that.
> 
> I'm guessing you did the same sort of thing that old BASIC programs did,
> which was machine code in DATA statements poked into memory and then
> executed.  If your compiler translates integers to addresses in a
> straightforward way, it would be pretty easy to do that in C.

Very likely that is what I did.  Either that or I did inline assembly 
since my compiler supported that option.  I used information/techniques 
from the books Undocumented DOS (1e) and the Abacus book on DOS 
programming.  Still have both of those on the bookshelf at home.

Jim

Post a reply to this message