Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!nntp-feed.chiark.greenend.org.uk!ewrotcd!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Gregory Ewing Newsgroups: comp.lang.python Subject: Re: OT: This Swift thing Date: Sun, 08 Jun 2014 13:25:07 +1200 Lines: 24 Message-ID: References: <8738fjkc2w.fsf@dpt-info.u-strasbg.fr> <53929baf$0$29988$c3e8da3$5496439d@news.astraweb.com> <53936148.1070109@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net dfJ0KzlI2hCB5bu7FhbHlgEOD9MVzHtQti0k63GAZkzgVPllKD Cancel-Lock: sha1:Ws9KYFFf5UOfID4bEg+7RTpGciA= User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en In-Reply-To: Xref: csiph.com comp.lang.python:72946 Dennis Lee Bieber wrote: > Not "standard" Pascal... It had pointer types, but no means to "stuff" > an integer into the pointer variable in order to dereference it as a memory > address... Although most implementations would let you get the same effect by abusing variant records (the equivalent of a C union). > What is an interrupt -- > typically a handler (function) address stored in a fixed location used by > the CPU when an external hardware signal goes high... Nothing prevents one > from writing that handler in C and using C's various casting operations to > stuff it into the vector memory. Most CPU architectures require you to use a special "return from interrupt" instruction to return from a hardware interrupt handler. So you need at least a small assembly language stub to call a handler written in C, or a C compiler with a non-standard extension to generate that instruction. -- Greg