Roller Coaster

It's been almost 30 years, when I first heard "Only thing is constant in High Tech is Change".

I can't think of anything better than that to reflect our experience, hence the notion about the state of affairs of it.

So what are the Changes, that we should be worried, interested, or otherwise curious ? - It's just two things. First Deep Learning, next Quantum computing. In another 5 years, they would be the main stream of knowledge(s) one would be required to someone who would - For me only thing that is constant is Change.

I like those two area, just because I've some bias in Mathematics and Statistics. I think once I was quite well trend in those areas, but was not easy to have a job where I could use for fun and profit !

Quantum Computation and Quantum Information and Deep Learing are two books I'm about to embark on. Well, I have had to start, so I started now.

Why are they important? Well, they are being already exploited, and going to be the next stage of High Tech. Most people using wide variety of devices directly or indirectly already gets the benifits of them, jus they don't know that behind the scene those are cropping up to play major roles. In one word - AI.

 Recently, I got engaged in Corporate Research for new and customer facing engaging product(s). Yeah, only thing constant is ... Also I really did not want to retire being called Senior engineer. I've had that title for quite some years, and I know very well when someone is retired, they get the title Senior and would be waiting for Tuesday of everyweek to get discount on almost everything, at least where I live...


Posted on Wednesday, January 10, 2018 at 06:48PM by Registered CommenterProkash Sinha | CommentsPost a Comment

Tid Bits of stack

What is stack? And what it is used for?

Stack is really a way to handle modularity of software. In the long past stack was designed and crafted by hands when most softwares were built using Assembly language. First the idea is to breakdown large code to manageable functions, and being called by yet other functions. So there had to be a way to pass arguments at call time, and revert back to the state where it was among other things. The result is stack machine, in the sense that the underlying architecture have enough support to create standard template code for stack paradigm.

After that stack became a software pattern that is one of the Abstract Data Type. Queue, list, doubly ended queue are some of the others.

 Now a days, whenever one function calls another function there is stack management work going on.

At the start of a function ( in most systems) the following is a standard prologue -

push %rbp

move %rsp %rbp

rbp is the frame pointer, and rsp is the stack pointer. So system pushes frame pointer on the stack. Now the stack pointer is free to be messed up by the callee. And at the end it can be retrieved from %rbp ( frame pointer).

How ???  When we define local variables to be used by a function, system reserve space to hold those local variables value. Followng code just do that ---

sub 0x48 %rsp; 

You can see that %rsp now changed and pointing to lower addressed memory. Stack grows downward.

In this case the local variables taking 0x48 bytes to hold the local variables current values.

Now after the computation within this function, it has to put back the frame pointer, as well clean up the current stack built, using following ---

mov %rbp %rsp ;  // rsp was untouched ( never used for anything ), so it gets back the stack pointer.

pop %rbp

%rbp being the frame pointer, and never suppose to be used as a target of any operation except the prologue and the epilog ( previous two lines is called epilog), where ever a local variable is used in the computation, it uses %rbp like a reference point. Like

mov -0x8(%rbp) %rbx.

add  $0x1 %rbx

More ...

Posted on Monday, May 22, 2017 at 09:32PM by Registered CommenterProkash Sinha | CommentsPost a Comment

Stack walk and why I'm here ?

Lot of OS provides ready APIs for stack walk programmatically, that can give us a trace like stack snap-shot when something go wrong and your application crashes. Most popular OS provides debugger and trouble shooting features that can help determine where and why something went wrong.

But it is not a piece of cake when you think you have to craft something right into kernel, and watch how things are happening. This is deep probe in my belief. So here are some background work that needs to be considered first --

-- why do we need to do. In other words, why am I here ?

-- What are the known and unknows? It could be a wide range of knowledge in general computer science.

-- How can I get some control of the kernel ?

-- How best I can craft a stack walk ?

-- What to look after I know that stack walk is working somewhat to my satisfaction ?

I've been able to finish this project/investigation and can see the result first hand.


Posted on Friday, December 30, 2016 at 06:43PM by Registered CommenterProkash Sinha | CommentsPost a Comment | References1 Reference

Looking forward to 2017 and beyond!

Time flies, and we are just about to enter another year. Time and again I bumped into this thing we call stack back trace. For last 10 or so years I always thought that it would be nice to get good grasp of this lethal weapon, compareable to a sharp knife and sharper brain of a surgeon. If one can understand this then lot of todays technology and their underlying thoughts and implementation becomes clear.

One can use it for lots of different things. Debugger uses it all the time, so it is not a new ground breaking technology. But its use is unbelievably wide in range. In this continuing series of notesf, I will try to emphasize one such implementation, that perhaps some of us could call "Beautiful code", and some of its use. It will cover an wide range of topics like: assembler, symbol constructions, application binary interfaces and standards, register sets and its purpose with respect to activation records.Finally its incarnation into the kernel.


More coming ...

Posted on Wednesday, December 7, 2016 at 07:25PM by Registered CommenterProkash Sinha | CommentsPost a Comment | References1 Reference

2016 year end reflection - Beautiful code

We are nearing the end of 2016, and holiday season is around us. I've appreciated code that by looking at it, I can tell it is well written. Then are some of them in the category of Beautiful code !

When I read a small article or a short stories about anything, if it can hold me engaged and I understand the flow and theme without much effort, I call it beautifully written. I've always thought about my writing that I could call beautiful code even merginally!

I recently wrote something to tackle some xnu virtual file system code that can alter program behavior depending how nice or rogue that program. So there was a deep dive into the xnu kernel code. The idea is to take early control of program execution, and see if it make sense to let a foreign program to play on your backyard.

As it turned out that depending on core kernel changes, there could be few things that needs to be checked even if I can not decide if it is going to harm or not.

So the idea, that it will make sure it keep a tab on those undecidable situations and learn of them on the fly. It will learn some traits that will drive the decision to take control.

I call this beautiful code, since it is a passive observer of the traits of foreign programs without even knowing by anyone its presence. Since it is in the kernel, it must be fault proof.

Posted on Saturday, November 5, 2016 at 09:09AM by Registered CommenterProkash Sinha | CommentsPost a Comment | References1 Reference