Jump to content

Low level programming languages

Hi P

[ Link for Context ]

 

I came across a post on Reddit that gave me a chuckle, which brought two questions to my head:

 

1.- The lower level the language is, the more permissions you have?

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

 

Thank you

Link to comment
Share on other sites

Link to post
Share on other sites

3 minutes ago, Hi P said:

1.- The lower level the language is, the more permissions you have?

not sure if permission is the right word here, but it does give more options in the code.

 

3 minutes ago, Hi P said:

 

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

dangerous as in blowing up hardware, no. It's more risky to break software and do unexpected things though

CPU: i7-2600K 4751MHz 1.44V (software) --> 1.47V at the back of the socket Motherboard: Asrock Z77 Extreme4 (BCLK: 103.3MHz) CPU Cooler: Noctua NH-D15 RAM: Adata XPG 2x8GB DDR3 (XMP: 2133MHz 10-11-11-30 CR2, custom: 2203MHz 10-11-10-26 CR1 tRFC:230 tREFI:14000) GPU: Asus GTX 1070 Dual (Super Jetstream vbios, +70(2025-2088MHz)/+400(8.8Gbps)) SSD: Samsung 840 Pro 256GB (main boot drive), Transcend SSD370 128GB PSU: Seasonic X-660 80+ Gold Case: Antec P110 Silent, 5 intakes 1 exhaust Monitor: AOC G2460PF 1080p 144Hz (150Hz max w/ DP, 121Hz max w/ HDMI) TN panel Keyboard: Logitech G610 Orion (Cherry MX Blue) with SteelSeries Apex M260 keycaps Mouse: BenQ Zowie FK1

 

Model: HP Omen 17 17-an110ca CPU: i7-8750H (0.125V core & cache, 50mV SA undervolt) GPU: GTX 1060 6GB Mobile (+80/+450, 1650MHz~1750MHz 0.78V~0.85V) RAM: 8+8GB DDR4-2400 18-17-17-39 2T Storage: HP EX920 1TB PCIe x4 M.2 SSD + Crucial MX500 1TB 2.5" SATA SSD, 128GB Toshiba PCIe x2 M.2 SSD (KBG30ZMV128G) gone cooking externally, 1TB Seagate 7200RPM 2.5" HDD (ST1000LM049-2GH172) left outside Monitor: 1080p 126Hz IPS G-sync

 

Desktop benching:

Cinebench R15 Single thread:168 Multi-thread: 833 

SuperPi (v1.5 from Techpowerup, PI value output) 16K: 0.100s 1M: 8.255s 32M: 7m 45.93s

Link to comment
Share on other sites

Link to post
Share on other sites

6 minutes ago, Hi P said:

[ Link for Context ]

 

I came across a post on Reddit that gave me a chuckle, which brought two questions to my head:

 

1.- The lower level the language is, the more permissions you have?

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

 

Thank you

1) Not really.  AFAIIK modern X86 processors do not let you at the arbitrary architecture that exists behind the X86 translation layer.  ARM and others may allow this however.

 

Also, modern CPUs are almost never below Ring 0.  Full hardware access needs what is effectively Ring -1 (maybe even Ring -2 or -3 depending on the platform, Intel's vPro security processor lives down there on their platforms).  Everything that is above the lowest Ring is virtualized to some degree.

 

2) You are more likely to hard-lock the system or corrupt data.

Link to comment
Share on other sites

Link to post
Share on other sites

21 minutes ago, Hi P said:

1.- The lower level the language is, the more permissions you have?

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

Meh, I don't agree with the first claim. All the languages I've seen so far could be coaxed into giving you direct access to all memory and registers of a system, it's just the amount of work needed to get to that point which is different; in C/C++/similar languages and assembler, there are no barriers to try and make it more difficult for you, but in e.g. Python you need to jump through several hoops to get there -- it's still possible to do it, if you insist!

 

As for the second one: you can mess something up in pretty much any language, if you try hard enough, like e.g. if you start messing around directly with the power-management ICs. No language is inherently more dangerous than another, though. Some languages have those barriers I mentioned, but they primarily exist to protect your own app from your own mistakes -- if you fuck something up, you're likely to introduce security-vulnerabilities in your own app or crash it, not something else running on your system, and all those barriers and helper-functionalities in some of these languages make it harder for you to make those kinds of mistakes.

Hand, n. A singular instrument worn at the end of the human arm and commonly thrust into somebody’s pocket.

Link to comment
Share on other sites

Link to post
Share on other sites

Well it is possible to get undefined behavior in C/C++, this might be an interesting read for additional info on that https://blog.regehr.org/archives/213

 

Beyond that you can maybe use values that would otherwise be protected by a higher level language? For instance maybe you're programming a controller and give it a voltage that it can't handle so you fry it or the device it's controlling and a higher level language or library could have protected you from that?

Link to comment
Share on other sites

Link to post
Share on other sites

If you program in assembly, you can mess with anything and everything. None of the rules/restrictions of a higher programming langauge applies. There is no concepts of scope, no access modifier, no limit on the ways you can manipulate memory. You can increment the value of an address of a variable with another address of another variable. You can load the value of a integer at an address and add it to a value of a string at another address. There is no concept of types. Everything is possible.... In other words you have so much room and potential to screw up in every lines of code you write. Figuring the long lines of code you wrote is a nightmare, debugging is a nightmare within a nightmare. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, ElfFriend said:

Beyond that you can maybe use values that would otherwise be protected by a higher level language? For instance maybe you're programming a controller and give it a voltage that it can't handle so you fry it or the device it's controlling and a higher level language or library could have protected you from that?

That's not how programming-languages work. For a language to be able to tell what are or aren't safe values, support for the controller would have be a baked-in feature of the language itself. Also, you can perfectly well write a library that checks what values its being supplied in any of these languages, including assembler. That's not a language-feature and does not require higher-level language.

Hand, n. A singular instrument worn at the end of the human arm and commonly thrust into somebody’s pocket.

Link to comment
Share on other sites

Link to post
Share on other sites

4 minutes ago, wasab said:

If you program in assembly, you can mess with anything and everything. None of the rules/restrictions of a higher programming langauge applies. There is no concepts of scope, no access modifier, no limit on the ways you can manipulate memory. You can increment the value of an address of a variable with another address of another variable. You can load the value of a integer at an address and add it to a value of a string at another address.

Don't need assembler-language for that.

Hand, n. A singular instrument worn at the end of the human arm and commonly thrust into somebody’s pocket.

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, WereCatf said:

That's not how programming-languages work. For a language to be able to tell what are or aren't safe values, support for the controller would have be a baked-in feature of the language itself. Also, you can perfectly well write a library that checks what values its being supplied in any of these languages, including assembler. That's not a language-feature and does not require higher-level language.

Good point, I guess I just blindly assumed that since python is used on a pi and it's aimed at amateurs there would be something to check that you're not doing anything too stupid?

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, ElfFriend said:

Good point, I guess I just blindly assumed that since python is used on a pi and it's aimed at amateurs there would be something to check that you're not doing anything too stupid?

Yes, the various libraries that exist for e.g. controlling the GPIO-pins generally do check what values you are giving them. That's not a language-feature. That's just a feature of those libraries. Besides, many of those libraries are written in C or C++.

Hand, n. A singular instrument worn at the end of the human arm and commonly thrust into somebody’s pocket.

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, Hi P said:

Is it dangerous? as in, could you mess something up in Assembler or C?

You can even mess something up in Python.

 

Learn the languages and, especially, learn from any mistakes. Then it will be fine.

Write in C.

Link to comment
Share on other sites

Link to post
Share on other sites

7 hours ago, Hi P said:

1.- The lower level the language is, the more permissions you have? 

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

  1. To quote Bill Clinton "That depends on what the definition of is is".
    1. If "permission" means that the language designers have given you their blessing to more easily fiddle with things directly, then sure.
    2. If "permission" means that the OS gives you more capabilities, no. It would have to be a very poorly designed OS to be secure for one language and not for another.
    3. Many languages which appear high level still allow you to do the "low level" things. For example, C# and Java allow "Unsafe" code, where you get to fiddle with pointers, ask for memory allocations, and such, which is essentially the only thing that languages like C and C++ offer that higher level languages "don't". You can even import external dlls, like the win32 API, and fiddle with "unmanaged" code that way. So to say that lower level languages allow you to do things that higher level languages don't is dubious at best.
    4. It's important to remember that, in this context, C/C++/x86 are actually high level languages. Yes, x86 is a high level language in this case. At no permission level do you get true atomic control of the processor, even from instructions that claim they are atomic: They are atomic to the programmers model only. There is no valid, listed, x86 instruction that leaves the processor in an unknown or invalid state. Those that do (like the f00f bug) are happy accidents.
  2. Well, you can mess things up in any language.
    1. If "mess things up" means make broken code, well that's a developer problem and not a language problem. You can do that in every language.
    2. If "mess things up" means "give users a hard time" you can do that fairly easily in any language. As an example, pick your favorite language, write a simple linked list implementation (you won't even need to be able to remove nodes), and make an infinite loop that continually adds a node to the linked list. Within a short while your computer should appear to crash.

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, straight_stewie said:

Many languages which appear high level still allow you to do the "low level" things. For example, C# and Java allow "Unsafe" code, where you get to fiddle with pointers, ask for memory allocations, and such, which is essentially the only thing that languages like C and C++ offer that higher level languages "don't".

C and C++ offer undefined behavior, which is one of the core principles of the language, it frees the implementation from having to perform all kinds of runtime checks and tests which would otherwise be required.

Link to comment
Share on other sites

Link to post
Share on other sites

4 hours ago, Dat Guy said:

You can even mess something up in Python.

Way back in school I accidentally made an un-deletable file in python. It confused the hell out of windows to the point where it was immune to del. Took remoting into it that file location with a linux machine to actually get rid of it.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

34 minutes ago, reniat said:

Way back in school I accidentally made an un-deletable file in python. It confused the hell out of windows to the point where it was immune to del. Took remoting into it that file location with a linux machine to actually get rid of it.

But...how?

Link to comment
Share on other sites

Link to post
Share on other sites

6 hours ago, WereCatf said:

Yes, the various libraries that exist for e.g. controlling the GPIO-pins generally do check what values you are giving them. That's not a language-feature. That's just a feature of those libraries. Besides, many of those libraries are written in C or C++.

I got have a question regarding this, mainly about Python.

 

By my understanding a library is a collection of modules, and modules are a collection of functions, right?

So does it mean Python can read functions written in C++ ?

Link to comment
Share on other sites

Link to post
Share on other sites

22 minutes ago, MyName13 said:

But...how?

I don't remember lol.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

8 minutes ago, Hi P said:

 

So does it mean Python can read functions written in C++ ?

Yes, but not directly. The C/C++ code needs to be compiled into a library, which you can then use with python. A lot of popular science/machine learning libraries actually do this behind the scenes to increase performance (im not sure if they use ctypes or some other way of linking, but they definitely use C/C++ libraries for the critical performance functions).

https://stackoverflow.com/questions/4241415/import-c-function-into-python-program

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

8 hours ago, WereCatf said:

Don't need assembler-language for that.

You do need an assembler language if you want to royally fck up. Compilers hold hands for you. Assembler isn't going to do that. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

13 hours ago, Hi P said:

1.- The lower level the language is, the more permissions you have?

Language has little to do with permissions. If you wrote an application in assembly that targets a modern OS, then you still have to deal with the OS's permission system. If you targeted something like DOS, which doesn't really have a permission system, or you are writing the OS then you have free reign practically. There are some processors though that do feature internal security models, but this is more to help the OS do its job.

 

However some systems, particularly with system management chips, are designed such that the programmer cannot touch the those parts of the system. Unless they poke at it hard enough to find the right combination of bits the designer didn't account for:

 

Quote

2.- Is it dangerous? as in, could you mess something up in Assembler or C?

Depends on what you mean by "dangerous." If you mean "crappy buggy programs," this is dependent on the programmer, not the language.

Link to comment
Share on other sites

Link to post
Share on other sites

41 minutes ago, Mira Yurizaki said:

Depends on what you mean by "dangerous." If you mean "crappy buggy programs," this is dependent on the programmer, not the language.

I think he meant dangerous like frying the CPU. Killing an SSD or mechanical HDD.

 

CPU if you try to access the mobo directly and change 1.43 volt to 10 volts maybe but i would guess they are all rom values once boot has completed therefore not modifiable. I'm no expert on frying CPU.

 

HDD and SSD those are pretty easy to screw up in nearly all languages but depend on what you are looking to achieve. I have experience in doing so with HDD but i can guess one way to kill it but it's a lot slower than HDD for sure. Much easier if you just want to force the installed OS to not work anymore than actually kill the disk definitively.

Link to comment
Share on other sites

Link to post
Share on other sites

6 minutes ago, Franck said:

Much easier if you just want to force the installed OS to not work anymore

programatically delete system32? :P

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

12 minutes ago, reniat said:

programatically delete system32? :P

hey you would be surprised to see that on windows 10 that is still a long shot. It usually still boot to a blue screen and auto repair then boot properly. It's a tough bastard ?

Link to comment
Share on other sites

Link to post
Share on other sites

On 3/8/2019 at 3:58 AM, wasab said:

If you program in assembly, you can mess with anything and everything. None of the rules/restrictions of a higher programming langauge applies. There is no concepts of scope, no access modifier, no limit on the ways you can manipulate memory. You can increment the value of an address of a variable with another address of another variable. You can load the value of a integer at an address and add it to a value of a string at another address. There is no concept of types. Everything is possible.... In other words you have so much room and potential to screw up in every lines of code you write. Figuring the long lines of code you wrote is a nightmare, debugging is a nightmare within a nightmare. 

Jesus, I hope I never have to go that deep.

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×