|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> OK, that's what I wanted to know...
I have learned I have a knack for figuring out what technical question
someone is *really* asking. I wish I knew why, so I could teach others
to do it.
> (PS. Is there more than one interrupt level available? Or does it decide
> which routine to call based on some other parameter?)
It depends on the CPU. Often there are multiple software interrupts
available, but most OSes only use one, with a parameter passed in a
register to indicate which one. Under MS-DOS, for example, it
was INT 21 (hex 21) to call DOS. The BIOS had a different interrupt
(13?) for disks, and maybe one for the other stuff like video and all.
Learning how basic CPU stuff works is often very useful. Like,
understanding that interrupts are nothing but polling the interrupt
hardware wire at the start of each instruction can make you go "Oh! I
see!" :-)
--
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
|
|
| |
| |
|
|
|
|
| |
|
|