Last visit was: Fri Jul 19, 2024 5:11 am
It is currently Fri Jul 19, 2024 5:11 am



 [ 9 posts ] 
 JUMP TO / COME FROM opcode ? 
Author Message

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 54
The JUMP / CALL / BRANCH opcode is not very interesting as such.

I believe there have been a few April Fools descriptions of a COME FROM opcode that is supposed to be the target of a jump, though I'm not sure what the point of it was; possibly security or something.

However, in all seriousness, are there any architectures which has something like a "COME FROM" opcode that can be used as a start of function/entry marker, or check that you are not jumping into code somewhere at random and then flow into the function start?
The logical way to do this would of course be to use a synchronous interrupt with an ILLEGAL/TRAP or whatever function the architecture uses for priviledge escalation which can then check that the conditions for entry are correct, but this is typically an expensive operation and I was looking for some ideas to cheapen this.

(This train of thought comes from my dealings with the Amiga operating system which is totally unprotected, and then pondering how you could try and keep non- and priviledged calls together while running as much as possible in a local context in an updated and modern version of the OS - probably SASOS like.)


Thu Feb 14, 2013 2:50 pm

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
I've never heard of such a thing; but without a "come from" op code, I suppose you could always call it like a subroutine and have it immediately check the return address on the stack and see if it's a legal one.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Thu Feb 14, 2013 7:08 pm WWW

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 54
NorthWay wrote:
I believe there have been a few April Fools descriptions of a COME FROM opcode

Found a mention of it: http://en.wikipedia.org/wiki/COMEFROM


Fri Feb 15, 2013 12:31 am

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 54
Garth wrote:
I've never heard of such a thing; but without a "come from" op code, I suppose you could always call it like a subroutine and have it immediately check the return address on the stack and see if it's a legal one.

As I said, I was looking for "cheaper" ways of achieving this. Something like an internal bit that gets cleared by every opcode, except JUMP/BRANCH that sets it and so a COMEFROM can check if that bit was set.

(On second thought - only a JSR/BSR or risc type "jump and link" opcode would be useful as they have a return address to rely on.)


Fri Feb 15, 2013 12:37 am
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
I guess it's a dated concept now, but Intel's x86 family features the "call gate" -- you're familiar with this? http://en.wikipedia.org/wiki/Call_gate Actually I know little about it myself, but I read about it years ago and it popped into mind when I saw your post.

Quote:
As I said, I was looking for "cheaper" ways of achieving this. Something like an internal bit that gets cleared by every opcode, except JUMP/BRANCH that sets it and so a COMEFROM can check if that bit was set.
The Call Gate idea doesn't sound cheap, does it! :( But your idea of a bit that's checked sounds OK.

Do I understand correctly that the goal is to prevent arrival at the function entry via simple fall-through from preceding inline code? What about placing a jump-to-self instruction just before the entry point -- is that a naive notion? (I have lots of experience with bits & gates, but I'm anything but an expert when it comes to OS privilege levels!)

Jeff

_________________
http://LaughtonElectronics.com


Fri Feb 15, 2013 5:51 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1789
It's not quite COMEFROM, but in CPUs without a stack, such as early computers and the modern Propeller CPU, to call a subroutine it's necessary to record the return address. So the caller writes their address just ahead of the entry point, and the called routine terminates by jumping back through that pointer. It allows any depth of subroutine, and for multiple call sites, but it doesn't allow for recursion (or re-entrancy)

In the early arguments about ALGOL, there was a paper arguing that subroutines should not be allowed to be recursive unless they declared themselves as such - because of the expense of implementation. Indeed, there was a lot of resistance to the usefulness of recursion which was seen as being of only academic interest. Which is true, from a perspective of number-crunching computing, but not so true when it comes to general symbolic manipulation, such as a compiler might do.

Cheers
Ed


Fri Feb 15, 2013 2:22 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2104
Location: Canada
What I'd like to know is: what happens when multiple COME-FROM's all point to the same source ? Does the processor spawn new threads of execution so that all the COME-FROMs can execute, or what ? Or are they prioritized somehow ?

COME FROM is an implementable instruction. It would work like a breakpoint. Store the COME-FROM source address in a register array (assuming multiple outstanding COME-FROM's). then do a jump when the current address matches an address in the array. It requires parallel compares and a register array.

Alternately, the COME-FROM could store a jump instruction back to the COME-FROM at the source address. It would be self modifying code.

_________________
Robert Finch http://www.finitron.ca


Fri Feb 15, 2013 2:56 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2104
Location: Canada
Quote:
or check that you are not jumping into code somewhere at random and then flow into the function start?


Quote:
What about placing a jump-to-self instruction


Slight modification: One could put a 'jump to bad flow handler' instruction in just before the function start to prevent code from flowing into the function.

One could setup a table of 'valid caller sources' in memory somewhere, then search the table to see if the call is valid. But it is an expensive operation cycle wise.
The instruction at the start of the subroutine would have a pointer to the valid caller table. The return address would have to be compared to table entries. It's almost the same kind of search that a linker would have to do when linking programs. Depending on the function, there might be many callers of it.

Another thought is to provide a 'key' argument to the subroutine. If the key doesn't match what's expected, then refuse to do the subroutine.

_________________
Robert Finch http://www.finitron.ca


Fri Feb 15, 2013 8:44 pm WWW

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 54
Dr Jefyll wrote:
Do I understand correctly that the goal is to prevent arrival at the function entry via simple fall-through from preceding inline code?

Well, this all lives in the twilight zone in my head where it is only a 60% refined idea of what I'm trying to achieve.

I do not want someone just jumping into the code at some point of their own desire. (Classically you would just not map that code in at user level, but as I have mentioned I'm an old-fashioned Amiga user trying to find angles to drag it kicking and screaming into the present with all the expected "proper" OS features.)
I want library/OS (function calls) to be cheap
- do not raise privilege levels if the function does not need it (isn't GetPID the classic no-op system call used for OS speed tests&optimizing?)
- do raise, but stay in the caller context if you can
- do raise into kernel context if needed

This thinking bleeds into my other topic about using MMU status to control behaviour. Something like "all instructions in this part of memory are flagged to cause an exception when they try to complete" (because they run in a too low ring?), except ENTER/COMEFROM(or some other entry point thing - ELEVATE?) which elevates your level by 1 and so suddenly you have the rights to run the code in that memory page. A very limited privilege level which is barely more than your average userlevel.


Sat Feb 16, 2013 3:33 am
 [ 9 posts ] 

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software